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Chapter  1 

Introduction 


In  November  2010,  the  Under  Secretary  of  Defense  (Acquisition,  Technology  and 
Logistics),  USD(AT&L),  issued  a  memorandum  establishing  the  business  capabi¬ 
lity  lifecycle  (BCL)  as  the  model  for  Department  of  Defense  (DoD)  components 
to  use  when  acquiring  a  defense  business  system  (DBS) — specifically,  any  DBS 
with  an  estimated  life-cycle  cost  of  more  than  $1  million.  USD  (AT&L)  issued 
policy  in  Directive-Type  Memorandum  (DTM)  1 1-009,  “Acquisition  Policy  for 
Defense  Business  Systems  (DBS),”  in  June  2011.  BCL  policy  is  projected  to  be 
included  in  the  updated  Department  of  Defense  Instruction  (DoDI)  5000.02,  “Op¬ 
eration  of  the  Defense  Acquisition  System,”  and  guidance  will  be  incorporated 
into  the  Defense  Acquisition  Guidebook  (DAG)  in  FY12. 

The  specific  purpose  of  this  guide  is  to  help  components  follow  the  BCL  process, 
develop  the  required  documentation,  and  receive  the  required  approvals.  Appen¬ 
dix  A  lists  key  resources  that  provide  guidance,  best  practices,  templates,  and  oth¬ 
er  infonnation  that  may  be  useful  to  program  managers  (PMs). 

The  BCL  leverages  DoD  tools  and  technologies,  such  as  the  Business  Enterprise 
Architecture  (BEA),  enterprise  transition  plan,  and  investment  review  boards 
(IRBs).  It  is  guided  by  six  tenets: 

♦  Rapidly  deliver  capability  to  the  end  user. 

♦  Focus  the  PM  on  program  execution  rather  than  program  justification. 

♦  Enable  timely  decision  making  while  reducing  bureaucracy. 

♦  Base  acquisition  decisions  on  appropriate  information. 

♦  Allow  acquisition-related  decisions  to  be  made  at  the  appropriate  level,  ra¬ 
ther  than  being  pushed  to  the  highest  level  possible. 

♦  Allow  for  flexibility  in  program  implementation  strategies. 

The  goals  for  the  BCL  is  to  rapidly  deliver  the  capability  to  the  user  and  allow 
DoD  to  more  readily  adapt  to  new  and  changing  business  requirements. 

To  provide  for  a  documentation  and  approval  process  appropriate  to  a  DBS’s 
complexity,  cost,  and  cross-organizational  impact,  DoD  separates  investments 
into  acquisition  categories  (ACATs).  This  guide  is  for  managers  assigned  respon¬ 
sibility  for  an  ACAT  III  program — a  program  whose  estimated  cost  for  all  ex¬ 
penditures  does  not  exceed  $32  million  (in  FY00  constant  dollars)  in  any  single 
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fiscal  year,  $126  million  (in  FYOO  constant  dollars)  for  all  expenditures  beginning 
in  the  Investment  Management  (IM)  phase  through  deployment  at  all  sites,  or 
$378  million  (in  FYOO  constant  dollars)  beginning  in  the  IM  phase  through  the 
Operations  and  Support  (O&S)  phase  for  the  estimated  life  of  the  system. 

Program  Manager’s  Qualifications, 
Responsibilities,  and  Interactions 

Qualifications 

For  an  ACAT  III  program  to  be  successful,  the  PM  should  understand  DBS 
implementation  principles,  have  management  skills,  and  have  experience  with 
relevant  nondevelopmental  business  applications  and  architectures.  The  PM  is 
accountable  for  the  successful  development  and  deployment  of  the  DBS.  It  is  crit¬ 
ical  that  the  appropriate  component  authorities  select  PMs  with  the  suitable  back¬ 
ground  and  competency  in  information  technology  (IT)  solutions,  as  well  as  the 
ability  to  build  and  manage  multidisciplinary,  integrated  teams  and  to  identify  and 
mitigate  risk.  In  addition,  the  PM  must  be  capable  of  interacting  effectively  with 
other  key  players  in  the  BCL  of  an  ACAT  III  program. 

Program  management  training  is  available  through  the  Defense  Acquisition  Uni¬ 
versity  (DAU).  DAU’s  catalog  is  available  at  http://icatalog.dau.mil/.  To  apply  for 
a  DAU  course,  go  to  http://www.dau.mil/studentInfo/Pages/ 
Military%20personnel%20Welcome.aspx. 

Responsibilities  and  Interactions 

Table  1-1  identifies  key  BCL  players  and  describes  their  general  responsibilities 
in  an  ACAT  III  program.  Subsequent  chapters  contain  additional  details  regarding 
phase-specific  responsibilities.  The  Component  Acquisition  Decision  Authority 
(CADA)  is  equivalent  to  a  service’s  Chief  Management  Officer  (CMO).  Outside 
the  services,  the  Component  Acquisition  Executive  (CAE)  detennines  who  will 
fill  this  role. 

Table  1-1.  Key  Players  in  the  BCL  of  an  ACAT  III  Program 


Role 

General  responsibilities 

CAE 

♦  Designates  the  Milestone  Decision  Authority  (MDA)  for  an  ACAT  III  DBS. 

Pre-Certification 
Authority  (PCA) 

♦  Assesses  and  precertifies  compliance  with  the  BEA  and  ensures  that  required  doc¬ 
umentation  is  available  for  IRB  review  prior  to  the  IRB  meeting. 

♦  Determines  whether  defense  agencies’  DBS  modernization  investments  and  in¬ 
vestments  that  will  support  the  business  processes  of  more  than  one  military  de¬ 
partment  or  defense  agency  have  adequately  performed  business  process 
reengineering  (BPR)  and  comply  with  the  BEA. 

♦  Ensures  that  BPR  has  been  performed  in  accordance  with  10  U.S.C.  § 

2222(a)(1)(A). 
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Table  1-1.  Key  Players  in  the  BCL  of  an  ACAT  III  Program 


Role 

General  responsibilities 

Defense  Business 
Systems  Management 
Committee  (DBSMC) 

♦  Advises  the  DBSMC  chair,  who  is  responsible  for  approving  certification  of  funds 
associated  with  modernization  efforts. 

CADA 

♦  Determines  whether  DBS  programs  within  his  or  her  area  of  responsibility  have  ad¬ 
equately  performed  BPR  and  whether  DBSs  comply  with  the  BEA. 

♦  Prepares,  approves,  and  submits  the  analysis  of  alternatives  (AoA)  study  guidance 
to  Component  Functional  Sponsor. 

♦  Approves  the  AoA  study  plan. 

♦  Reviews  and  provides  independent  assessments  of  cost  estimates  and  cost  anal¬ 
yses  as  appropriate. 

♦  Submits  approved  AoA  study  guidance  and  AoA  study  plan  to  the  IRB  chair. 

Component  Chief 
Information  Officer 
(CIO) 

♦  Works  with  the  component,  IRBs,  DBSMC,  and  other  stakeholders  to  ensure  the 
development  of  DBSs  in  compliance  with  applicable  statutes  and  regulations  and  in 
accordance  with  DoD  policy  on  architecture,  design,  interoperability,  security,  and  in¬ 
formation  assurance. 

Component  Functional 
Sponsor 

♦  Identifies  and  obtains  funding  for  all  phases  throughout  the  BCL. 

♦  Is  responsible  for  the  Doctrine,  Organization,  Training,  Leadership  and  Education, 
Personnel,  Facilities,  and  Policy  (DOTmLPF-P)  nonmaterial  portions  of  the  solution. 

♦  Represents  the  user’s  needs  throughout  the  process. 

♦  Develops  the  AoA  study  plan  in  coordination  with  the  IRB  and  in  accordance  with 
CADA-approved  AoA  study  guidance. 

IRB 

♦  Reviews  the  following  documents  to  certify  they  are  in  accordance  with  Title  10  USC 
2222: 

■  Problem  statement,  which  must  be  approved  by  the  IRB  chair 

■  Requirements  changes  and  technical  configuration  changes,  for  programs  in  de¬ 
velopment,  that  could  affect  cost  and  schedule 

■  Business  case. 

MDA 

♦  Makes  DBS  acquisition  decisions  and  determines  the  appropriate  BCL  entry/ 

acquisition  phases.  The  MDA  will  not  approve  program  changes  unless  the  program 
increment  is  fully  funded  and  schedule  impacts  mitigated.  The  MDA  does  the  follow¬ 
ing: 

■  Establishes  mandatory  procedures  for  assigned  programs 

■  Tailors  regulatory  information  requirements  and  acquisition  processes  and  proce¬ 
dures  to  achieve  cost,  schedule,  and  performance  goals 

■  Submits  reports  to  Congress  as  required  by  statute. 

PM 

♦  Is  accountable  for  the  successful  development  and  deployment  of  the  DBS. 

Overview  of  the  BCL  Process 


The  BCL  is  composed  of  seven  phases:  Business  Capability  Definition  (BCD), 
IM,  Prototyping,  Engineering  Development,  Limited  Fielding,  Full  Deployment, 
and  O&S.  At  the  highest  level,  the  BCL  model  can  be  viewed  as  consisting  of  two 
phases  and  one  segment: 

♦  BCD  phase.  The  purpose  of  the  BCD  phase  is  to  analyze,  understand,  and 
scope  an  identified  a  problem,  need,  or  gap.  The  BCD  phase  ends  when 
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the  IRB  chair  approves  the  problem  statement  and  the  CADA  submits  the 
approved  AoA  study  guidance  and  AoA  study  plan  to  the  MDA  for  the 
Materiel  Development  Decision  (MDD). 

♦  IM phase.  The  IM  phase  begins  with  an  MDD  by  the  MDA.  The  purpose 
of  this  phase  is  to  conduct  an  AoA,  recommend  a  preferred  Doctrine,  Or¬ 
ganization,  Training,  Materiel,  Leadership  and  Education,  Personnel,  Fa¬ 
cilities,  and  Policy  (DOTMLPF-P)  solution  and  deliver  a  plan  (business 
case)  to  satisfy  the  business  need  in  the  approved  problem  statement.  It  is 
an  iterative  process  that  will  result  in  a  strategy  and  plan  that  can  be  exe¬ 
cuted  to  field  useful  capability.  The  IM  phase  ends  when  the  PM  forwards 
a  complete  Milestone  A  package,  including  the  business  case  and  the 
DBSMC  certification  of  the  availability  of  funds,  to  the  MDA. 

♦  Execution  segment.  The  Execution  segment,  which  begins  with  a  Mile¬ 
stone  A  decision,  encompasses  the  Prototyping,  Engineering  Develop¬ 
ment,  Limited  Fielding,  Full  Deployment,  and  O&S  phases.  The 
segment’s  purpose  is  to  design,  develop,  test,  and  deploy  the  solution,  in 
accordance  with  the  business  case  and  the  program  charter,  and  to  operate 
and  support  the  solution.  Key  decision  points  as  the  solution  proceeds 
through  the  Execution  segment  are  Milestone  B,  Milestone  C,  and  Full 
Deployment  Decision  (FDD).  During  the  Execution  segment,  IRB  reviews 
occur  annually.  However,  recertification  is  required  when  additional  capi¬ 
tal  investment  above  a  previously  certified  amount  is  needed  or  additional 
time  outside  of  the  originally  certified  fiscal  year  period  is  needed  on  the 
same  modernization  effort.  The  Execution  segment  ends  when  the  DBS 
reaches  the  end  of  its  useful  life  and  requires  disposal. 

Figure  1-1  is  a  high-level  view  of  the  BCL  process  and  the  associated  milestones 
and  decision  points. 

Figure  1-1.  BCL  Milestones,  Phases,  and  Segment 
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The  focus  of  BCL  is  streamlining,  utilizing  the  business  case  for  decision  making 
and  keeping  documents  at  the  program  level  for  execution.  Appendix  B  describes 
the  documentation,  certification  and  approval  requirements,  approval  authority, 
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and  the  nature  of  each  requirement  (statutory  or  regulatory).  Appendix  C  des¬ 
cribes  the  DBS  documentation. 

Organization  of  the  Guide 


Chapters  2,  3,  and  4,  respectively,  guide  you  through  the  BCL:  BCD  phase,  IM 
phase,  and  the  Prototyping,  Engineering  Development,  Limited  Fielding,  Full  De¬ 
ployment,  and  O&S  phases  within  the  Execution  segment.  The  appendixes  con¬ 
tain  supporting  detail. 
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Chapter  2 

Business  Capability  Definition  Phase 


The  purpose  of  the  BCD  phase  is  to  analyze,  understand,  and  scope  an  identified 
problem,  need,  or  gap.  The  outcome  of  the  BCD  phase  is  a  thorough  understan¬ 
ding  of  the  problem,  need,  or  gap  at  a  root  cause  level  and  the  identification  of  the 
desired  outcome,  or  what  “good”  looks  like  when  the  problem  is  solved. 

The  BCD  phase  begins  with  the  identification  of  a  business  need.  The  BCD  phase 
ends  when  the  IRB  chair  approves  the  problem  statement  and  the  CADA  submits 
the  approved  AoA  study  guidance  and  AoA  study  plan  to  the  MDA  for  the  MDD. 
Figure  2-1  emphasizes  the  role  the  IRB  and  the  MDA  play  in  this  phase. 


Figure  2-1.  Business  Capability  Definition  Segment 
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Roles  and  Responsibilities 


Table  2-1  lists  the  roles  and  responsibilities  associated  with  the  BCD  phase. 
Table  2-1.  Roles  and  Responsibilities:  Business  Capability  Definition  Phase 


Role 

Responsibilities 

CADA 

♦  Approves  and  submits  required  documentation  through  the  IRB/DBSMC  process. 

♦  Prepares  AoA  study  guidance. 

♦  Submits  AoA  study  guidance  and  AoA  study  plan  to  the  MDA. 
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Table  2-1.  Roles  and  Responsibilities:  Business  Capability  Definition  Phase 


Role 

Responsibilities 

Component 

Functional 

Sponsor 

♦  Leads  the  development  of  the  problem  statement. 

♦  Submits  the  problem  statement  to  the  IRB. 

♦  Works  closely  with  the  CADA  to  guide  initiatives  and  investments  through  the  IRB/DBSMC 
process. 

♦  Facilitates  the  BPR  process. 

♦  Ensures  user  needs  are  represented. 

♦  Defines  measurable  high-level  business  outcomes. 

♦  Develops  the  AoA  study  plan  in  coordination  with  the  IRB  and  in  accordance  with  CADA- 
approved  AoA  study  guidance. 

IRB 

♦  Recommends  IRB  chair  approval  of  proposed  solution  to  the  business  need  documented 
in  a  problem  statement  after  determining  that  it  is  aligned  with  DoD’s  strategic  goals  and 
objectives;  that  it  addresses  a  problem,  a  capability  gap,  or  functional  requirement  in  the 
functional  portfolio;  and  that  it  is  not  duplicative  of  a  solution  (materiel  or  nonmateriel)  al¬ 
ready  in  place. 

Phase  Description 


The  BCD  phase  begins  with  the  component  identification  of  a  business  need.  Be¬ 
cause  the  BCD  phase  occurs  only  one  time  within  the  program’s  life  cycle,  it  is 
crucial  that  the  analysis  of  the  business  need  be  thorough,  complete,  and  compre¬ 
hensive.  Though  anyone  can  identify  a  business  need,  the  Component  Functional 
Sponsor  of  the  business  area  in  which  the  need  resides  is  responsible  for  docu¬ 
menting  the  business  need  and  championing  the  problem’s  resolution  through  to 
completion  and  secure  funding.  The  Component  Functional  Sponsor  works  close¬ 
ly  with  the  functional  community  (end  users,  functional  subject  matter  experts, 
and  other  key  stakeholders)  to  conduct  the  analysis.  The  process  culminates  in  the 
development  of  a  problem  statement  summarizing  the  analysis  and  defining 
measurable  outcomes  for  the  program.  The  Component  Functional  Sponsor  sub¬ 
mits  the  problem  statement  to  the  IRB  not  less  than  30  days  prior  to  the  IRB 
meeting. 

Problem  Statement 


The  problem  statement  and  its  supporting  analysis  are  some  of  the  most  important 
products  developed  during  the  BCL.  They  serve  as  the  foundation  for  all  subse¬ 
quent  analyses.  Upon  completion  of  the  BCD  phase  analysis,  the  Component 
Functional  Sponsor  must  document  the  results  in  a  clearly  defined  and  well- 
scoped  problem  statement,  which  then  becomes  the  foundation  of  the  business 
case.  Appendix  D  contains  a  detailed  description  of  a  BCL  business  case.  The 
IRB  and  MDA  use  the  problem  statement  to  determine  whether  a  materiel  solu¬ 
tion  should  be  pursued. 
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Business  Capability  Definition  Phase 


The  problem  statement  must,  at  minimum,  address  the  following: 

♦  Context  of  the  business  need  (e.g.,  the  organization’s  operating  environ¬ 
ment  and  mission) 

♦  Business  need,  stated  and  defined  within  the  context  (expressed  in  a  man¬ 
ner  that  is  specific  and,  where  possible,  quantitative) 

♦  Root  cause — one  or  more  factors  that  when  fixed,  eliminates  the  prob¬ 
lem — of  the  business  need,  including  analytic  or  statistical  evidence  if 
possible  to  prove  that  the  root  cause  of  the  business  need  has  been  reliably 
identified 

♦  Business  need  boundaries  and  constraints  (organizational,  functional,  in¬ 
frastructure) 

♦  Results  of  the  (DOTmLPF-P  non-materiel)  analysis  and  impact  on  the  as- 
is  process 

♦  Potential  solutions  for  solving  the  business  need  and  providing  the  specific 
intended  benefits  (must  include  BPR)  and  describing  the  to-be  business 
process  to  enable  an  effective  AoA  study  to  be  conducted 

♦  Desired  outcome  and  measures/metrics  derived  from  addressing  the  busi¬ 
ness  need  (impact  on  the  future  strategic  and  business  operating  environ¬ 
ment  in  specific,  quantitative  terms) 

♦  Constraints  and  assumptions,  resulting  from  the  DOTMLPF-P  analysis,  af¬ 
fecting  the  BPR 

♦  Recommended  potential  solutions  for  investigation 

♦  Rough  order  of  magnitude  cost  estimate  for  any  potential  solution  that 
entails  a  materiel  solution. 

Root  Cause  and  DOTMLPF-P  Analysis 


Once  a  business  need  is  identified,  the  Component  Functional  Sponsor,  in  collab¬ 
oration  with  the  functional  community,  leads  a  thorough  analysis  to  determine  the 
root  cause  of  the  identified  business  need.  This  helps  the  functional  community 
understand  and  define  the  business  need  at  a  solvable  level.  It  also  ensures  the  re¬ 
liability  of  the  infonnation  in  the  problem  statement.  During  the  root  cause  analy¬ 
sis,  the  functional  community  will  typically  do  the  following: 

♦  Assemble  evidence  (historical  performance  statistics,  funding  trends,  and 
audit  reports). 
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♦  Compare  key  pieces  of  information  and  look  for  relationships  or  patterns 
(industry  benchmarks,  mission-area  outcome  goals,  and  same  or  similar 
functions). 

♦  Quantify  various  courses  of  action  (consequences  of  continuing  with  sta¬ 
tus  quo  and  expected  effects  after  the  status  quo  is  changed). 

It  is  vital  that  the  root  cause  analysis  be  free  of  bias  and  assumption  and  that  it 
identifies  a  root  cause  or  causes,  rather  than  symptoms  or  aggravating  factors  of  a 
root  cause. 

After  identifying  the  root  cause  of  the  business  need,  the  Component  Functional 
Sponsor  conducts  a  DOTMLPF-P  framework-based  analysis  of  the  business  need. 
This  analysis  determines  the  benefits  and  constraints.  Though  there  is  no  univer¬ 
sally  accepted  framework  for  conducting  a  DOTMLPF-P  analysis,  it  must,  at 
minimum,  address  the  following  questions: 

♦  Is  the  root  cause  a  result  of  a  lack  of  training  or  of  generally  inadequate 
training? 

♦  Do  the  senior  officials  understand  the  scope  of  the  root  cause? 

♦  Is  the  issue  caused,  at  least  in  part,  by  inability  or  decreased  ability  to 
place  qualified  and  trained  personnel  in  occupational  specialties? 

After  completing  the  root  cause  analysis,  DOTMLPF-P  analysis,  and  to-be  analy¬ 
sis,  the  Component  Functional  Sponsor  develops  initial  materiel  or  nonmateriel 
solution  options;  defines  specific,  measurable  objectives  and  outcomes;  and  iden¬ 
tifies  metrics  for  measuring  the  degree  to  which  the  business  need  has  been  satis¬ 
fied.  The  following  must  be  established  before  the  other  BCD  phase  activities 
may  proceed: 

♦  Does  the  problem  statement  present  a  valid  case  to  prove  that  the  identi¬ 
fied  business  needs  warrants  investment? 

♦  Do  the  BPR  efforts  result  in  enough  streamlining  and  efficiencies  to  war¬ 
rant  investment? 

Business  Process  Reengineering 


BPR  provides  an  organization  a  methodology  to  review,  analyze,  document  or 
map,  and  improve  its  business  processes.  DoD  defines  BPR  as  a  logical  method 
for  assessing  process  weaknesses,  identifying  gaps,  and  implementing  opportuni¬ 
ties  to  streamline  and  improve  these  processes  to  create  a  solid  foundation  for 
success  in  changes  to  the  full  spectrum  of  operations.  BPR  is  part  of  business  pro¬ 
cess  management  (BPM),  which  is  a  holistic  management  approach  focused  on 
aligning  all  aspects  of  an  organization  with  the  wants  and  needs  of  clients. 
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Business  Capability  Definition  Phase 


It  promotes  business  effectiveness  and  efficiency,  while  striving  for  innovation, 
flexibility,  and  integration  with  technology.  BPM  attempts  to  improve  processes 
continuously.  It  can  therefore  be  described  as  a  “process  optimization  process.” 

The  initial  BPR  is  the  basis  on  which  the  materiel  solution  will  be  implemented. 
Technology  availability  will  significantly  affect  BPR  implementation. 

DoD  does  not  mandate  the  use  of  a  specific  BPR  method.  However,  the  method 
should  allow  the  project  team  to  map,  document,  and  analyze  the  current  process; 
identify  gaps,  defects,  and  inefficiencies  in  the  process;  and  identify  ways  to  im¬ 
prove  the  process.  The  Office  of  the  Deputy  Chief  Management  Officer 
(ODCMO)  offers  a  36  hour  class  on  the  DoD  approach  to  BPR  DoD  lists  the  fol¬ 
lowing  key  tenets  for  accomplishing  BPR: 

♦  A  clear  and  reasonable  problem  statement 

♦  Demonstrated  alignment  of  the  investment  with  broader  department,  com¬ 
ponent,  or  service  goals 

♦  As-is  analysis  in  sufficient  detail  to  illuminate  the  problem. 

Appendix  E  discusses  DoD’s  approach  to  BPR  and  the  integration  of  BPR  into 
the  IRB  process.  For  additional  guidance  on  BPR,  see  “Guidance  to  the  Imple¬ 
mentation  of  Section  1072-Business  Process  Reengineering,”  issued  by  ODCMO 
on  April  30,  2011. 

AoA  Study  Guidance  and  Study  Plan 


Within  30  days  of  the  IRB  approving  the  problem  statement,  the  CAD  A  prepares 
and  submits  the  AoA  study  guidance  to  the  Component  Functional  Sponsor. 

Within  30  days  of  receipt  of  the  AoA  study  guidance,  the  Component  Functional 
Sponsor  develops  an  AoA  study  plan  based  on  the  approved  AoA  study  guidance 
and  submits  it  to  the  CADA  for  approval.  The  CADA  submits  the  AoA  study 
guidance  and  AoA  study  plan  to  the  responsible  IRB  chair. 

Exit  Criteria 


The  BCD  phase  ends  with  approval  of  the  problem  statement  by  the  IRB  chair 
and  submission  of  the  AoA  materials  to  the  IRB  chair  (or  appropriate  component- 
level  governance  forum).  If  a  problem  statement  is  solely  nomnateriel,  the  BCD 
ends  when  the  problem  statement  is  approved,  because  no  AoA  will  be  required. 
Table  2-2  lists  the  information  submission  requirements  for  the  BCD  phase,  and 
shows  the  authority  or  nature  of  the  requirement. 
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Table  2-2.  Required  Information:  Business  Capability  Definition  Phase 


Required  information 

Approval  or  certification  authority/ 
nature  of  requirement 

Problem  statement 

IRB  chair/regulatory 

BPR 

IRB  chair/statutory 

AoA  study  guidance 

CAD  A/regulatory 

AoA  study  plan 

CAD  A/regulatory 

2-6 


Chapter  3 

Investment  Management  Phase 


The  purpose  of  the  IM  phase  is  to  conduct  an  AoA,  recommend  a  preferred 
DOTMLPF-P  solution,  and  deliver  a  plan  (business  case)  to  satisfy  the  business 
need  identified  in  the  approved  problem  statement.  It  is  an  iterative  process  that 
will  result  in  a  strategy  and  plan  that  can  be  executed  to  field  useful  capability. 

The  outputs  and  outcome  of  IM  phase  are  as  follows: 

♦  A  completed  AoA  that  enables  the  Component  Functional  Sponsor  and 
PM  to  recommend  a  preferred  solution  for  solving  the  business  need. 

♦  A  well-defined  business  and  technical  management  approach  that  de¬ 
scribes  how  the  effort  will  achieve  its  objectives  using  the  preferred  solu¬ 
tion.  The  business  case  summarizes  those  functional  plans  and  strategies. 

♦  A  program  charter  defining  roles  and  responsibilities  for  the  potential  pro¬ 
gram. 

Figure  3-1  details  the  PCA’s  role  and  the  relationship  of  the  IRB/DBSMC’s  certi¬ 
fication  to  the  MDA’s  Milestone  A  decision. 

Figure  3-1.  Investment  Management  Phase 
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Roles  and  Responsibilities 


Table  3-1  lists  the  roles  and  responsibilities  associated  with  the  IM  phase.  The  PM 
is  listed  first,  followed  by  other  roles  in  alphabetical  order. 
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Table  3-1.  Roles  and  Responsibilities:  Investment  Management  Phase 


Role 


PM 


♦ 


♦ 


♦ 

♦ 

♦ 


♦ 


♦ 


♦ 


♦ 


CADA 


♦ 

♦ 


CAE 


♦ 

♦ 


DBSMC 


♦ 

♦ 


Component 

Functional 

Sponsor 


♦ 

♦ 

♦ 

♦ 


♦ 


♦ 

♦ 

♦ 


♦ 


♦ 


IRB/IRB  chair 

MDA 


♦ 

♦ 

♦ 

♦ 

♦ 


Responsibilities 

Ensures  whatever  is  analyzed,  selected,  or  scheduled  can  be  executed  within  specified 
timeline. 

Ensures  that  the  proposed  materiel  solution  documented  in  the  business  case  complies 
with  all  statutory  and  regulatory  requirements. 

In  coordination  with  the  Component  Functional  Sponsor,  collaborates  on  the  business 
case,  as  appropriate. 

Signs  the  program  charter. 

In  coordination  with  the  Component  Functional  Sponsor,  defines  the  program  outcomes 
that  support  the  business  outcomes. 

In  coordination  with  the  Component  Functional  Sponsor,  refines  the  program  outcomes 
during  the  AoA  (if  assigned  prior  to  the  AoA). 

Oversees  the  program  activities  necessary  to  ensure  that  the  proposed  materiel  solution 
demonstrates  compliance  with  statutory  and  regulatory  requirements,  such  as  the  Clinger- 
Cohen  Act  (CCA). 

Updates  the  BPR  based  the  solution  selected  as  a  result  of  the  AoA. 

Ensures  completion  and  mitigation  of  an  independent  risk  assessment. 

Prepares  for  the  IRB  certification. 

Approves  system  test  plan. 

Approves  milestone  documentation. 

Signs  the  business  case. 

Approves  the  program  charter. 

Coordinates  its  investment  oversight  responsibilities  with  the  MDA  for  each  DBS  it  re¬ 
views. 

Provides  input  to  the  development  of  DBS  investment  and  acquisition  policies. 

Approves  IRB  certification  recommendations. 

Presents  the  approved  AoA  study  guidance  and  AoA  study  plan  at  the  MDD  review. 
Presents  the  business  need  described  in  the  IRB-approved  problem  statement  at  the 
MDD  review. 

Ensures  DBS  investments  are  aligned  to  their  functional  areas  and  meet  strategic  busi¬ 
ness  priorities. 

Leads  the  development  of  the  proposed  non-materiel  solution’s  business  case. 

Ensures  user  needs  are  represented. 

Ensures  that  all  necessary  funding  is  identified  and  obtained  to  support  the  DBS’s  pro¬ 
gress  through  the  BCL. 

Works  closely  with  appropriate  component  points  of  contact  to  guide  DBS  investments 
through  the  certification  process. 

Ensures  the  component  staff  is  engaged  as  appropriate  for  guidance  relating  to  the  acqui¬ 
sition  approach  and  test  plan  content  areas  of  the  business  case. 

Signs  the  business  case  and  the  program  charter. 

Integrates  the  DOTMLPF-P  solution  specified  in  the  business  case. 

Reviews  and  certifies  modernization  funds  pursuant  to  10  U.S.C. 

Tracks  identified  solutions  through  the  BCL. 

At  MDD,  reviews  the  IRB-approved  problem  statement,  AoA  study  guidance,  and  AoA 
study  plan;  specifies  the  acquisition  entry  phase  and  designates  the  next  milestone;  and 
issues  an  ADM  with  the  approved  AoA  study  guidance  and  AoA  study  plan  attached. 
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Investment  Management  Phase 


Table  3-1.  Roles  and  Responsibilities:  Investment  Management  Phase 


Role 

Responsibilities 

PCA 

♦  Prepares  a  memo  that  requests  certification  of  program  funding  and  defines  which  10 
U.S.C.  §  2222-defined  criteria  for  certification  the  system  is  seeking.  This  memo  authori¬ 
tatively  asserts  for  the  component  that  the  system 

■  has  provided  current,  complete,  and  accurate  information  required  for  certification; 

■  has  updated  information  in  the  DoD  Information  Technology  Portfolio  Repository 
(DITPR); 

■  is  or  plans  to  be  compliant  with  the  DoD  BEA; 

■  is  included  in  the  component  or  enterprise  transition  plan  as  appropriate;  and 

■  has  completed  and  verified  the  earned  value  (EV)  analysis  (if  required)  and  included  it 
along  with  the  certification  submission. 

♦  Uploads  the  memo  on  the  IRB  portal  along  with  the  other  requested  documentation. 

Phase  Description 


The  IM  phase  justifies  the  most  efficient  fulfillment  of  a  business  need  based  on 
thorough  analysis  and  planning  and  resulting  in  a  well-developed  business  case 
and  program  charter.  The  IM  phase  begins  at  the  MDD,  which  is  mandatory  for 
all  DBSs.  The  PM  is  assigned  early  in  the  IM  phase.  At  the  MDD,  the  Component 
Functional  Sponsor  presents  the  business  need  as  described  in  the  IRB -approved 
problem  statement,  and  the  CADA  presents  the  AoA  study  guidance  and  AoA 
study  plan  to  the  MDA.  The  MDA  decision — documented  in  an  Acquisition  Deci¬ 
sion  Memorandum  (ADM)  to  which  the  AoA  study  guidance  and  AoA  study  plan 
is  attached — specifies  the  acquisition  entry  phase  for  the  proposed  materiel  solu¬ 
tion  and  designates  the  next  milestone  review.  A  Milestone  A  review  must  be 
scheduled  to  occur  within  12  months  of  MDD  approval  unless  the  ADM  instructs 
otherwise. 

During  this  phase,  the  IRB  has  oversight  authority  for  investment  activities,  while 
the  MDA  has  acquisition  decision  authority  over  the  program,  with  input  from  the 
IRB. 

IM  phase  activities  include  the  analysis  necessary  to  describe  the  materiel  solu¬ 
tion;  the  solution  scope,  objectives,  business  outcomes,  outcome-based  perfor¬ 
mance  measures,  constraints,  and  dependencies;  the  program  justification, 
including  assumptions,  DOTMLPF-P  impact,  critical  success  factors,  risks,  de¬ 
tailed  cost  and  benefits  (including  return  on  investment,  which  can  include  finan¬ 
cial  and  nonfinancial  benefits),  funding  profile,  and  delivery  schedule;  and  an 
acquisition  and  contracting  approach.  In  addition,  the  PM  updates  the  BPR  based 
on  the  solution  selected  as  a  result  of  the  AoA. 

The  IM  phase  analysis  is  summarized  in  the  business  case  developed  and  signed 
by  the  Component  Functional  Sponsor  and  the  PM.  The  business  case  includes 
the  problem  statement  and  the  results  of  the  IM  phase  analysis  and  serves  as  the 
foundation  for  all  BCL  efforts  (except  program-level  execution)  and  decisions. 


3-3 


It  is  an  evolving,  executive-level  document  that  reflects  program  planning  and 
includes  summaries  of  required  infonnation  that  must  be  readily  available  to  other 
agencies  to  fulfill  their  statutory  or  other  duties. 

The  PM  and  the  Component  Functional  Sponsor  jointly  detennine  and  document 
technical  methods,  processes,  procedures,  and  responsibilities  by  which  the  poten¬ 
tial  program  will  be  managed,  evaluated,  controlled,  and  executed  by  the  govern¬ 
ment  and  the  contractor.  This  summary  of  systems  engineering  planning  includes 
program  requirements  management,  traceability,  and  verification;  architecture  and 
interface  definition  and  management;  configuration  and  change  management; 
technical  staffing  and  organization  management;  and  use  of  technical  reviews. 
This  technical  planning  must  be  summarized  in  the  business  case. 

The  PM  addresses  other  requirements,  including  data  management;  data  conver¬ 
sion;  records  management;  software  and  data  rights;  system  architecture;  systems 
integration;  training  materials;  user  training;  risk  management;  security  (infor¬ 
mation  assurance);  net  operations  requirements;  interoperability  and  supportabil- 
ity;  and  component,  integration,  system,  and  acceptance  testing.  These 
considerations  must  be  summarized  in  the  business  case. 

The  PM,  the  Component  Functional  Sponsor,  and  the  component’s  test  and  evalu¬ 
ation  (T&E)  community  jointly  develop,  and  include  in  the  business  case,  a  plan 
that  describes,  among  other  things,  an  integrated  test  program  schedule;  test  man¬ 
agement  structure  and  processes;  operational  test  and  evaluation  (objectives, 
events,  entrance  criteria,  scope,  and  limitations);  critical  technical  parameters; 
critical  operational  issues,  with  associated  measures  of  effectiveness  and  perfor¬ 
mance;  and  required  resources.  The  CAD  A  approves  the  initial  test  plan  and  up¬ 
dates  it  at  subsequent  decision  points. 

The  PM  and  the  Component  Functional  Sponsor  jointly  detennine,  and  document 
in  the  program  charter,  the  managerial  methods  and  responsibilities  by  which  the 
materiel  solution  will  be  executed  by  the  government  and  the  contractor.  The  PM, 
the  Component  Functional  Sponsor,  and  other  responsible  officials,  as  required, 
sign  the  program  charter.  Appendix  F  contains  detailed  infonnation  about  the 
charter. 

The  PCA  must  ensure  that  when  a  system  investment  successfully  completes  the 
internal  certification  process,  it  has:  been  assessed  against  and  complies  with  the 
DoD  BEA,  is  included  in  the  component  transition  plan,  and  validates  that  all 
required  system  information  is  loaded  into  the  DITPR  and  uploaded  on  the  IRB 
portal.  For  those  systems  submitted  to  DoD  IRBs  for  certification  review,  the 
PCA  will  prepare  a  standard  certification  package.  The  PCA  is  considered  the 
point  of  contact  for  any  communication  between  the  IRB  and  the  system’s  PM. 
The  PCA  also  asserts  that  any  documentation  and  artifacts  necessary  to  substan¬ 
tiate  infonnation  submitted  to  the  IRB  is  readily  available.  The  IRB  chair  submits 
its  recommendation  to  the  DBSMC,  resulting  in  a  DBSMC  chair  certification  ap¬ 
proval  memorandum. 
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Investment  Management  Phase 


At  the  end  of  the  IM  phase,  the  PM  compiles  a  milestone  decision  package  and 
submits  it  to  the  MDA  with  a  recommendation  for  a  milestone  decision.  The 
package  includes  the  business  case,  the  program  charter,  the  DBSMC  certification 
approval  memorandum,  and  risk  assessment  findings  and  associated  program  risk 
mitigation  plans.  Appendix  G  contains  additional  IT-related  requirements. 

Additional  Phase  Requirements 


The  Component  Functional  Sponsor  is  responsible  and  accountable  for  achieving 
the  nonmateriel  solution  specified  in  the  business  case. 

The  IRB  chair  is  responsible  and  accountable  for  tracking  identified  solutions 
through  the  BCL  and  for  reporting,  to  the  appropriate  authority,  the  status  and 
alignment  of  all  capabilities  in  the  portfolio  in  compliance  with  10  U.S.C.  §  2222. 

If  IM  phase  activities  exceed  12  months  from  the  signature  date  of  the  MDD 
ADM,  the  IRB  chair  will  review  the  business  need  and  advise  the  MDA  whether 
the  IM  phase  activities  should  be  continued  or  canceled. 

Exit  Criteria 


The  IM  phase  ends  when  phase  requirements  have  been  satisfied,  the  IRB  has 
reviewed  the  business  case,  and  the  PM  has  forwarded  a  Milestone  A  recommen¬ 
dation  to  the  MDA.  Table  3-2  lists  the  infonnation  required  for  a  Milestone  A  de¬ 
cision  and  shows  the  authority  or  nature  of  the  requirement.  DBSMC  certification 
authorizes  the  program  to  obligate  funds.  The  MDA’s  issuance  of  an  approved 
milestone  ADM  formally  authorizes  a  program  to  begin  the  Execution  segment. 

Table  3-2.  Required  Information:  Investment  Management  Phase — Milestone  A 


Information  required 

Approval  or  certification  authority/ 
nature  of  requirement 

BPR 

IRB/statutory — updated  as  necessary 

ADM 

MD  A/regulatory 

Business  case,  including  summaries  of  the  following  required 

MDA 

documents: 

♦  AoA 

CADA/regulatory 

♦  Cost  estimate 

CADA/regulatory 

♦  Market  research 

CADA/regulatory 

♦  Acquisition  approach,  including  summaries  of  the  following 
required  documents: 

■  Data  management  strategy 

CADA/statutory 

■  Lifecycle  sustainment  plan  (LCSP) 

CADA/regulatory 

■  Test  plan 

CADA/regulatory 
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Table  3-2.  Required  Information:  Investment  Management  Phase — Milestone  A 


Information  required 

Approval  or  certification  authority/ 
nature  of  requirement 

Risk  assessment 

CADA/regulatory 

AIAS  (DoDI  8500.2) 

CADA/regulatory 

Certification  of  compliance  with  10  U.S.C.  §  2222  (BEA) 

DCSMC/statutory  (before  obligation  of  funds) 

CCA  compliance 

CADA/statutory 

DoD  component  CIO  confirmation  of  CCA  compliance 

Component  ClO/statutory 

Program  charter 

CAE/regulatory 

Note:  AIAS  =  Acquisition  Information  Assurance  Strategy. 
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Chapter  4 

Execution  Segment 


The  Execution  segment  encompasses  the  Prototyping,  Engineering  Development, 
Limited  Fielding,  Full  Deployment,  and  O&S  phases  of  the  BCL.  The  purpose  of 
the  Execution  segment  is  to  design,  develop,  test,  and  deploy  the  solution  in  ac¬ 
cordance  with  the  business  case  and  the  program  charter. 

To  meet  the  BCL’s  primary  goal  of  delivering  a  solution  to  a  problem,  need,  or 
gap,  key  decision  points  are  scheduled  as  the  solution  proceeds  through  the  Exe¬ 
cution  segment:  Milestone  B,  Milestone  C,  and  Full  Deployment  Decision.  The 
solution  may  be  deployed  in  increments:  initial  functionality  and  additional  capa¬ 
bility  increments.  The  Execution  segment  ends  when  the  DBS  reaches  the  end  of 
its  useful  life  and  requires  disposal. 

Figure  4-1  delineates  the  key  decision  points  during  the  Execution  segment.  An¬ 
nual  IRB  reviews  are  required  for  the  life  of  the  program. 


Figure  4-1.  Execution  Segment 


Roles  and  Responsibilities 

Table  4-1  lists  the  roles  and  responsibilities  associated  with  the  Execution  seg¬ 
ment.  The  PM  is  listed  first,  followed  by  other  roles  in  alphabetical  order. 
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Table  4-1.  Roles  and  Responsibilities:  Execution  Segment 


Role 


PM 


♦ 

♦ 


♦ 

♦ 

♦ 

♦ 

♦ 


♦ 


CADA 


♦ 


Component  ♦ 

Functional  Sponsor  + 


♦ 


♦ 

♦ 

♦ 

♦ 

♦ 

♦ 

♦ 

♦ 


♦ 


♦ 


♦ 

♦ 


IRB/IRB  chair 


♦ 


MDA 


♦ 


♦ 


Responsibilities 


Updates  the  program  charter. 

In  coordination  with  the  Component  Functional  Sponsor,  collaborates  on  updates  to  the 
business  case,  as  appropriate. 

In  coordination  with  the  Component  Functional  Sponsor,  ensures  the  technical  solution 
fulfills  the  user’s  prioritized  requirements. 

Oversees  the  activities  necessary  to  ensure  that  the  materiel  solution  complies  with 
statutory  and  regulatory  requirements. 

Coordinates  the  component  risk  assessment. 

Prepares  for  the  IRB,  Milestone  B,  Milestone  C,  and  FDD  reviews. 

Executes  against  the  cost,  schedule,  and  performance  described  in  the  Acquisition  Pro¬ 
gram  Baseline  (APB)  and  MDA  requirements,  if  any,  that  are  documented  in  an  ADM. 
Delivers  the  business  capabilities  described  in  the  business  case  for  an  increment. 
Approves  and  submits  required  milestone  documentation. 

Ensures  stakeholder  engagement. 

Optimizes  operational  readiness. 

Works  with  appropriate  component  points  of  contact  to  guide  DBS  investments  through 
the  IRB/DBSMC  process. 

Ensures  user  needs  are  represented. 

Leads  the  development  and  prioritization  of  remaining  functional  requirements,  as  nec¬ 
essary  and  appropriate. 

Ensures  DBS  investments  are  aligned  to  their  functional  areas  and  meet  strategic  busi¬ 
ness  priorities. 

Validates  current  BPR  and  facilitates  further  BPR,  as  necessary. 

Updates  the  business  case  as  required. 

Defines  IOC  and  Full  Deployment  (FD). 

Ensures  that  the  materiel  solution  documented  in  the  business  case  complies  with  all 
statutory  and  regulatory  requirements. 

Ensures  that  all  necessary  funding  is  identified  and  obtained  to  support  the  DBS’s  pro¬ 
gress  through  the  BCL. 

Ensures  component  staff  is  engaged  as  appropriate  for  guidance  relating  to  the  acquisi¬ 
tion  approach  and  test  plan  included  in  the  business  case. 

Integrates  and  achieves  the  DOTMLPF-P  solution  specified  in  the  business  case  and, 
as  appropriate,  updates  BPR  as  appropriate. 

Declares  IOC  and  Full  Operational  Capability  (FOC). 

Reviews  sustainment  strategies,  comparing  performance  expectations  as  defined  in 
performance  agreements  and  the  business  case  to  actual  performance  results. 

Reviews  and  certifies  additional  modernization  funds  pursuant  to  10  U.S.C.,  as  neces¬ 
sary. 

Tracks  identified  solutions  through  the  BCL  and  reports,  to  the  appropriate  authorities, 
the  status  and  alignment  of  all  capabilities  in  the  portfolios. 

Approves  the  business  case. 


♦  Provides  milestone  and  FDD  approval,  each  documented  in  an  ADM. 
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Execution  Segment 


Prototyping  Phase 


The  purpose  of  the  Prototyping  phase  is  to  demonstrate  the  capability  of  the  soft¬ 
ware  to  meet  business  requirements  as  outlined  in  the  business  case.  Prototyping 
includes  installing  IT  in  a  relevant  environment  to  gain  the  knowledge  necessary 
to  refine  user  requirements  and  support  APB  development.  The  amount  of  proto¬ 
typing  required  for  COTS  programs  is  likely  to  be  minimal. 

The  Prototyping  phase  begins  when  the  MDA  has  approved  the  business  case  and 
has  documented  the  Milestone  A  decision. 

During  the  Prototyping  phase,  the  PM  completes  detailed  design  and  installation 
of  the  selected  IT  in  a  relevant  environment  to 

♦  demonstrate  the  capability  of  the  software  to  meet  business  process  re¬ 
quirements  as  outlined  in  the  business  case; 

♦  detennine  the  software  usability,  accessibility,  and  utility  from  the  end 
user’s  perspective; 

♦  define  and  predict  performance  under  peak  loads; 

♦  evaluate  other  technical  aspects  of  the  software;  and 

♦  evaluate  the  design  approach  to  meet  the  capability  needed. 

The  PM  compiles  a  Milestone  B  acquisition  decision  package  and  submits  it  to 
the  IRB  for  review.  After  review,  the  IRB  chair  forwards  a  Milestone  B  recom¬ 
mendation  to  the  MDA,  completing  the  Prototyping  phase. 

Engineering  Development  Phase 


The  purpose  of  the  Engineering  Development  phase  is  to  demonstrate  that  the  ma¬ 
teriel  solution  has  been  designed,  configured,  and  tested  in  a  manner  consistent 
with  the  approved  business  case  and  program  charter  and  that  the  materiel  solu¬ 
tion  is  ready  for  limited  testing  in  an  operational  environment. 

The  Engineering  Development  phase  begins  when  the  MDA  has  approved  the  up¬ 
dated  business  case  and  APB  and  has  documented  the  decision  in  a  Milestone  B 
ADM. 

During  the  Engineering  Development  phase,  the  PM  refines  system  requirements, 
configures  the  software,  builds  functionality  as  required,  conducts  developmental 
testing,  and  plans  for  operational  testing.  The  PM  designs  the  maintenance  pro¬ 
gram  to  minimize  total  life-cycle  cost  while  achieving  readiness  and  sustainability 
objectives. 
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The  Engineering  Development  phase  ends  when  phase  requirements  have  been 
satisfied  and  when  the  functional  sponsor  has  reviewed  the  test  results  and  deter¬ 
mined  that  the  outcomes  and  metrics  as  stated  in  the  approved  business  case  have 
been  satisfied. 

Table  4-2  lists  the  infonnation  requirements  for  the  Milestone  B  decision  and 
shows  the  authority  or  nature  of  the  requirement. 


Table  4-2.  Required  Information:  Engineering  Development  Phase — Milestone  B 


Required  information 

Approval  or  certification  authority/ 
nature  of  requirement 

Program  charter 

CAE/regulatory — updated 

BPR 

IRB/statutory — updated 

ADM 

MD  A/regulatory 

Business  case,  including  summaries  of  the  following  required  documents: 

MD  A/regulatory — updated 

♦  Cost  estimate 

♦  Acquisition  approach,  including  summaries  of  the  following  required 
documents: 

CADA/regulatory — updated 

■  Data  management  strategy 

CADA/statutory — updated 

■  Information  support  plan  (ISP) 

CADA/regulatory 

■  LCSP 

C  AD  A/reg  u  lato  ry — u  pd  ated 

■  Test  plan 

CADA/regulatory — updated 

Risk  assessment 

CADA/regulatory 

AIAS  (DoDI  8500.2) 

CCM  O/regulatory 

APB 

MD  A/regulatory 

Certification  of  compliance  with  10  U.S.C.  §  2222  (BEA) 

IRB/statutory 

CCA  compliance 

CADA/statutory 

Component  CIO  confirmation  of  CCA  compliance 

Component  ClO/regulatory 

Programmatic  environment,  safety,  and  occupational  health  evaluation 
(including  National  Environmental  Policy  Act/Executive  Order  12114  and 
compliance  schedule  for  systems  requiring  hardware) 

CADA/statutory 

At  the  end  of  the  Engineering  Development  phase,  the  PM  compiles  a  Mile¬ 
stone  C  acquisition  decision  package  and  submits  it  to  the  MDA  with  a  recom¬ 
mendation  for  a  milestone  decision.  The  package  includes  the  updated  business 
case,  an  AIAS,  and  an  APB.  The  MDA  acknowledges  satisfaction  of  the  Engi¬ 
neering  Development  phase  requirements  in  an  ADM. 

Limited  Fielding  Phase 


The  purpose  of  the  Limited  Fielding  phase  is  to  deliver  the  developed  materiel 
solution  to  a  limited  number  of  users  and  to  conduct  OT&E.  This  phase  limits  risk 
by  determining  the  operational  effectiveness  and  suitability  of  the  system  before  it 
is  deployed  to  all  users. 
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Execution  Segment 


The  Limited  Fielding  phase  begins  when  the  functional  sponsor  and  the  MDA 
have  approved  fielding  the  capability  into  an  operational  environment  for  IOT&E 
and  when  the  MDA  has  documented  the  decision  in  a  Milestone  C  ADM. 

The  Component  Functional  Sponsor,  informed  by  IOT&E  results,  issues  a  written 
declaration  that  the  system  has  achieved  IOC. 

Table  4-3  lists  the  information  required  for  a  Milestone  C  decision  and  shows  the 
authority  or  nature  of  the  requirement. 

Table  4-3.  Required  Information:  Limited  Fielding  Phase — Milestone  C 


Required  information 

Approval  or  certification  authority/ 
nature  of  requirement 

ADM 

MD  A/regulatory 

Business  case,  including  summaries  of  the  following  required  documents: 

MD  A/regulatory — updated 

♦  Acquisition  approach,  including  summaries  of  the  following  required 
documents: 

■  Data  management  strategy 

CAD  A/statutory — updated 

■  ISP 

CAD  A/regulatory — updated 

■  LCSP 

CAD  A/regulatory — updated 

■  Test  plan 

C  AD  A/reg  u  lato  ry — u  pd  ated 

AIAS  (DoDI  8500.2) 

CADA/regulatory — updated 

APB 

M  D  A/reg  u  1  ato  ry — u  pd  ated 

Certification  of  compliance  with  10  U.S.C.  §  2222  (BEA) 

IRB/statutory — updated 

CCA  compliance 

CADA/statutory — updated 

Component  CIO  confirmation  of  CCA  compliance 

Component  Cl O/regulatory — 
updated 

Programmatic  environment,  safety,  and  occupational  health  evaluation 
(Including  National  Environmental  Policy  Act/Executive  Order  12114  and 
compliance  schedule  for  systems  requiring  hardware) 

CADA/statutory — updated 

During  the  Limited  Fielding  phase,  the  PM  verifies  that  the  functional  require¬ 
ments  and  DOTLMPF-P  parts  of  the  solution  described  in  the  business  case  are 
satisfied  and  that  it  is  a  holistic  solution  ready  for  deployment.  The  Component 
Functional  Sponsor,  infonned  by  IOT&E  results,  issues  a  written  declaration  that 
the  system  has  achieved  IOC. 

The  Limited  Fielding  phase  ends  when  phase  requirements  have  been  satisfied, 
IOT&E  is  complete,  and  the  Component  Functional  Sponsor  declares  IOC. 

Full  Deployment  Phase 


The  purpose  of  the  Full  Deployment  phase  is  to  field  an  increment  of  the  opera¬ 
tional  capability  in  accordance  with  the  business  case. 
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The  Full  Deployment  phase  begins  at  the  FDD,  when  the  MDA  reviews  the  busi¬ 
ness  case,  the  IOT&E  results,  and  the  FDD  documentation  requirements  to  deter¬ 
mine  whether  the  capability  is  ready  to  proceed  to  full  deployment;  the  MDA 
documents  the  decision  in  an  ADM.  The  Component  Functional  Sponsor  defines 
the  criteria  to  be  considered  for  an  FDD  and  full  deployment  in  the  business  case. 

Table  4-4  lists  the  documentation  requirements  for  the  FDD  phase. 


Table  4-4.  Required  Information:  Full  Deployment  Phase 


Required  information 

Approval  or  certification  authority/ 
nature  of  requirement 

Post-Implementation  Review 

CADA/regulatory 

Business  case,  including  summaries  of  the  following  required 
documents: 

MD  A/regulatory — updated 

♦  Acquisition  approach,  including  summaries  of  the  following  required 
documents: 

■  Data  management  strategy 

CAD  A/statutory — updated 

■  ISP 

CADA/regulatory — updated 

■  LCSP 

CADA/regulatory — updated 

■  Test  plan 

CADA/regulatory — updated 

AIAS  (DoDI  8500.2) 

CADA/regulatory — updated 

APB 

M  D  A/reg  u  1  ato  ry — u  pd  ated 

Certification  of  compliance  with  10  U.S.C.  §  2222  (BEA) 

IRB/statutory — updated 

CCA  compliance 

CAD  A/statutory — updated 

Component  CIO  confirmation  of  CCA  compliance 

Component  ClO/regulatory — updated 

The  Full  Deployment  phase  ends  when  the  conditions  imposed  by  the  MDA  at  the 
FDD  have  been  satisfied  and  the  Component  Functional  Sponsor  declares,  in  writ¬ 
ing,  that  the  system  has  achieved  full  deployment,  as  defined  in  the  business  case. 
The  PM  schedules  a  closeout  review  with  the  IRB  upon  completion  of  the  Full 
Deployment  phase.  The  review  is  done  in  accordance  with  the  Defense  Business 
Transformation  Agency’s  “DoD  IT  Defense  Business  Systems  Investment  Re¬ 
view  Process:  Guidance,”  January  2009,  and  includes  the  Post-Implementation 
Review  (PIR)  report.  The  purpose  of  the  closeout  review  is  to  determine  whether 
the  investment  has  achieved  the  outcomes  defined  in  the  business  case. 


Operations  and  Support  Phase 


The  purpose  of  the  O&S  phase  is  to  execute  a  support  program  that  meets  materi¬ 
el  readiness  and  operational  support  performance  requirements  and  ensures  cost- 
effective  sustainment  of  the  system  over  its  life  cycle.  Planning  for  this  phase  be¬ 
gins  prior  to  program  initiation  and  is  summarized  in  the  business  case. 
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Execution  Segment 


O&S  includes  user  support  and  hardware  and  software  maintenance  to  ensure  that 
the  system  meets  service  level  requirements. 

The  O&S  phase  begins  when  an  increment  or  DBS  has  been  fully  deployed.  The 
Component  Functional  Sponsor  continually  reviews  sustainment  strategies,  com¬ 
paring  performance  expectations,  as  defined  in  perfonnance  agreements  and  the 
business  case,  to  actual  results. 

The  O&S  phase  ends  when  the  DBS  reaches  the  end  of  its  useful  life  and  requires 
disposal.  The  PM  must  dispose  of  the  system  in  accordance  with  statutory  and 
regulatory  requirements,  considering  safety,  environment,  and  security  of  data  and 
information. 
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Appendix  A 

Key  Resources 


Armed  Forces,  10  U.S.C.  §  186,  2222  (a)(1)(B),  2222(f),  2222(g),  2366(a), 
2366(b),  2445(a),  and  2445(c). 

Clinger-Cohen  Act  of  1996,  40  U.S.C.  §  11103,  11313,  and  1 1317  and  Subtitle 
III,  Infonnation  Technology  Management. 

Defense  Acquisition  University,  “Defense  Acquisition  Guidebook.” 

Defense  Business  Transfonnation  Agency,  “DoD  IT  Defense  Business  Systems 
Investment  Review  Process,”  January  2009. 

Deputy  Chief  Management  Officer,  “Final  Guidance  for  the  Implementation  of 
Section  1072-Business  Process  Reengineering  (BPR),”  April  30,  2011. 

Directive-Type  Memorandum  08-020,  “Investment  Review  Board  (IRB)  Roles 
and  Responsibilities,  Incorporating  Change  1,”  September  3,  2010. 

Directive-Type  Memorandum  1 1-009,  “Acquisition  Policy  for  Defense  Business 
Systems,  Incorporating  Change  1,”  December  9,  201 1. 

DoD  Directive  5000.01,  “The  Defense  Acquisition  System,”  May  12,  2003. 

DoD  Instruction  5000.02,  “Operation  of  the  Defense  Acquisition  System,” 
December  8,  2008. 

DoD  Instruction  8410.02  “NetOps  for  the  Global  Infonnation  Grid  (GIG).” 

DoD  Instruction  8500.2,  “Infonnation  Assurance  (IA)  Implementation, 

February  2,  2003. 

National  Defense  Authorization  Act  for  FY  2005. 

National  Defense  Authorization  Act  for  FY  2010. 

National  Defense  Authorization  Act  for  FY  2012. 

National  Environmental  Policy  Act,  42  U.S.C.  §  4321  et  seq. 

Office  of  Management  and  Budget  Circular  A-130,  “Management  of  Federal  In¬ 
fonnation  Resources.” 
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Appendix  B 

Requirements  by  Milestone 


Table  B-l  lists  the  information  documentation  requirements  by  milestone  for 
ACAT  III  programs. 

Table  B-1.  Required  Information  for  Acquisition  Programs  Using  the  BCL 


Required  information 

When  required 

Approval  or  certification  authority/ 
nature  of  requirement 

AoA  study  guidance 

60  days  prior  to  MDD 

CAD  A/regulatory 

AoA  study  plan 

MDD 

CADA/regulatory 

Program  charter 

MSA 

Updated  at  MS  B 

CAE/regulatory 

Problem  statement 

30  days  prior  to  IRB 

IRB  chair/regulatory 

BPR 

MDD 

Updated  at 

♦  MSA 

♦  MS  B 

IRB/statutory 

ADM 

MDD 

MSA 

MS  B 

MS  C 

FDD 

MD  A/regulatory 

AIAS  (DoDI  8500.2) 

MSA 

MS  B 

MS  C 

FDD 

CADA/regulatory 

Business  case,  including  summaries 
of  the  following  required  documents: 

MSA 

Updated  at 

♦  MS  B 

♦  MSC 

♦  FDD 

MDA/statutory 

♦  AoA 

MSA 

MDA/statutory 

♦  Cost  estimate 

MSA 

Updated  at  MS  B 

CADA/regulatory 

♦  Market  research 

MSA 

CADA/statutory 
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Table  B-1.  Required  Information  for  Acquisition  Programs  Using  the  BCL 


Required  information 

When  required 

Approval  or  certification  authority/ 
nature  of  requirement 

♦  Acquisition  approach,  including  summaries 
of  the  following  required  documents: 

MSA 

MDA 

■  Consideration  of  technology  issues 

MSA 

CADA/statutory 

■  Data  management  strategy 

MSA 

Updated  at 

♦  MS  B 

♦  MSC 

♦  FDD 

CADA/statutory 

■  LCSP 

MSA 

Updated  at 

♦  MS  B 

♦  MSC 

♦  FDD 

CADA/regulatory 

■  Test  plan 

MSA 

MS  B 

MS  C 

FDD 

CAD  A/regulatory 

■  ISP 

MS  B 

Updated  at 
♦  MSC 

CADA/regulatory 

Certification  of  compliance 
with  10U.S.C.  §2222(BEA) 

Prior  to  obligation  of  funds 
MSA 

MS  B 

MS  C 

FDD 

DBSMC/statutory 

CCA  compliance 

MSA 

MS  B 

MS  C 

FDD 

CADA/statutory 

Component  CIO  confirmation 
of  CCA  compliance 

MSA 

MS  B 

MS  C 

FDD 

Component  ClO/statutory 

Risk  assessment 

MSA 

MS  B 

CADA/regulatory 
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Requirements  by  Milestone 


Table  B-1.  Required  Information  for  Acquisition  Programs  Using  the  BCL 


Required  information 

When  required 

Approval  or  certification  authority/ 
nature  of  requirement 

APB 

MS  B 

Updated  at 

♦  MSC 

♦  FDD 

MD  A/regulatory 

Programmatic  environment,  safety,  and  occu¬ 

MS  B 

CADA/statutory 

pational  health  evaluation 

MS  C 

FDD 

PIR 

FDD 

CADA/statutory 

Notes:  Statutes  and  regulations  require  development  of  certain  documents  through  rigorous  analysis.  These  documents  must  be 
developed  and  summaries  of  the  information  they  contain  are  included  in  the  business  case.  Individual  documents  are  not  expected 
to  be  coordinated  and  approved  at  the  OSD  level  unless  necessary  to  fulfill  statutory  or  other  duties  or  as  otherwise  specified.  The 
Component  Functional  Sponsor  will  provide  complete  copies  of  any  document  summarized  in  the  business  case  upon  request  of  the 
responsible  officials. 
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Appendix  C 

Documentation  Descriptions 


Table  C-l  describes  the  BCL  documentation  requirements  for  AC  AT  III 
programs. 

Table  C-1.  Documentation  Requirements  for  ACAT  III  Programs 


Required  information 

Description 

Acquisition  approach 

A  comprehensive,  integrated  plan  that  identifies  the  acquisition  approach  and 
describes  the  business,  technical,  and  support  strategies  that  management  will 
follow  to  manage  program  risks  and  meet  program  objectives.  The  acquisition 
strategy  should  define  the  relationship  between  the  acquisition  phases  and  work 
efforts  and  the  key  program  events  such  as  decision  points,  reviews,  contract 
awards,  test  activities,  production  lot/delivery  quantities,  and  operational  de¬ 
ployment  objectives. 

ADM 

A  memorandum,  signed  by  the  MDA,  that  documents  decisions  made  as  the 
result  of  a  milestone  decision  review  or  other  decision  or  program  review. 

AIAS  (DoDI  8500.2) 

Documentation  that  ensures  that  the  program  has  an  information  assurance 
strategy  consistent  with  DoD  policies,  standards,  and  architectures,  including 
relevant  standards. 

APB 

The  threshold  and  objective  values  for  the  minimum  number  of  cost,  schedule, 
and  performance  attributes  that  describe  the  program  over  its  life  cycle.  Cost 
values  reflect  the  life-cycle  cost  estimate;  scheduled  dates  include  key  activities 
such  as  milestones  and  the  IOC;  and  performance  attributes  reflect  the  opera¬ 
tional  performance  required  for  the  fielded  system.  Key  performance  parameters 
are  copied  verbatim  into  the  APB.  The  key  system  attributes  are  also  reflected  in 
the  APB.  Other  significant  performance  parameters  may  be  added  by  the  MDA. 

AoA 

An  analytical  comparison  of  the  operational  effectiveness,  suitability,  and  life- 
cycle  cost  (or  total  ownership  cost,  if  applicable)  of  alternatives  that  satisfy  estab¬ 
lished  capability  needs.  Initiated  after  the  MDD,  the  AoA  examines  potential  ma¬ 
teriel  solutions  with  the  goal  of  identifying  the  most  promising  option. 

AoA  study  guidance 

Guidance  for  carrying  out  the  AoA  study.  The  guidance  requires,  at  minimum,  full 
consideration  of  possible  tradeoffs  among  cost,  schedule,  and  performance 
objectives  for  each  alternative. 

AoA  study  plan 

A  road  map  that  describes  how  the  AoA  will  proceed  and  identifies  individual 
responsibilities.  At  minimum,  the  study  plan  should  facilitate  full  consideration  of 
possible  tradeoffs  among  cost,  schedule,  and  performance  objectives  for  each 
alternative  and  an  assessment  of  whether  the  joint  military  requirement  can  be 
met  in  a  manner  that  is  consistent  with  the  cost  and  schedule  objectives. 

Business  case 

A  summary  of  information  necessary  to  enable  effective  management  decisions 
resulting  from  the  rigorous  analysis  and  associated  documentation  produced  by 
the  Component  Functional  Sponsor  and  program  manager.  The  business  case 
clearly  defines  and  articulates  the  business  problem,  the  desired  outcomes,  and 
the  holistic  plan  for  delivering  the  capability.  It  is  continually  updated  as  more 
knowledge  is  acquired  through  the  BCL. 
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Table  C-1.  Documentation  Requirements  for  ACAT  III  Programs 


Required  information 

Description 

BPR 

A  logical  method  for  assessing  process  weaknesses,  identifying  gaps,  and  im¬ 
plementing  opportunities  to  streamline  and  improve  these  processes  to  create  a 
solid  foundation  for  success  in  changes  to  the  full  spectrum  of  operations. 

Certification  of  compliance 
with  10  U.S.C.  §2222  (BEA) 

A  self-assertion  of  compliance  with  a  specific  version  of  DoD’s  BEA,  as  required 
by  10  U.S.C. 

CCA  compliance 

Satisfaction  of  IT  system  acquisition  justification  requirements  per  Subtitle  III  of 
Title  40  U.S.C.  (Clinger-Cohen  Act). 

Cost  estimate 

A  judgment  or  opinion  regarding  the  cost  of  an  object,  commodity,  or  service. 

The  estimate  is  a  result  or  product  of  an  estimating  procedure  that  specifies  the 
expected  dollar  cost  required  to  perform  a  stipulated  task  or  to  acquire  an  item. 
The  cost  estimate  may  constitute  a  single  value  or  a  range  of  values. 

Data  management  strategy 
(DMS) 

A  strategy  or  plan  for  managing  all  forms  of  recorded  information  (both  govern¬ 
ment  and  contractor-created  data),  regardless  of  the  method  of  recording.  The 
DMS  must  be  integrated  in  the  acquisition  strategy  and  with  other  LCSPs  prior  to 
issuing  a  solicitation. 

Component  CIO  confirmation 
of  CCA  compliance 

Confirmation  that  the  requirements  of  Section  1 1313  of  Subtitle  III  of  40  U.S.C. 
(Title  40/CCA)  have  been  satisfied.  Confirmation  is  required  for  non-major  pro¬ 
grams  and  information  technology  systems,  including  national  security  systems, 
before  the  MDA  may  initiate  a  program  or  an  increment  of  a  program  or  approve 
entry  into  any  phase  of  the  acquisition  process,  or  before  the  DoD  component 
may  award  a  contract. 

ISP 

A  plan  that  addresses  the  information-related  needs  of  an  acquisition  program  in 
support  of  the  operational  and  functional  capabilities  the  program  either  delivers 
or  contributes  to.  The  ISP  provides  a  means  to  identify  and  resolve  potential  in¬ 
formation  support  implementation  issues  and  risks  that,  if  not  properly  managed, 
will  limit  or  restrict  the  ability  of  a  program  to  be  operationally  employed  in  ac¬ 
cordance  with  the  defined  capability.  The  plan  focuses  on  net-readiness,  in¬ 
teroperability,  information  supportability,  and  information  sufficiency  concerns. 

The  ISP  process  is  one  of  discovery,  requiring  analysis  of  the  program’s  inte¬ 
grated  architecture  and  processes  associated  with  meeting  a  capability.  This 
analysis  identifies  information  need,  net-centric,  interoperability,  and  supportabil¬ 
ity  issues  and  assesses  compliance  with  DoD  information  policy  and  goals. 

LCSP 

A  plan  that  demonstrates  the  early  planning,  development,  implementation,  and 
management  of  a  comprehensive,  affordable,  effective  performance-driven 
logistics  support  strategy.  The  LCSP  plays  a  key  role  during  all  phases  of  the  life 
cycle.  Its  purpose  is  to  ensure  integration  of  sustainment  considerations  into  all 
planning,  implementation,  management,  and  oversight  activities  associated  with 
the  acquisition,  development,  production,  fielding,  support,  and  disposal  of  a  sys¬ 
tem  across  its  life  cycle. 

Market  research 

The  process  of  collecting  and  analyzing  information  about  capabilities  within  the 
market  to  satisfy  agency  needs.  Market  research  consists  of  gathering  data  on 
business  and  industry  trends,  characteristics  of  products  and  services,  suppliers’ 
capabilities,  and  related  business  practices. 

PIR 

A  DOTMLPF  assessment  process  for  planning,  aggregating,  and  analyzing  in¬ 
formation  needed  to  evaluate  the  degree  to  which  a  materiel  investment  operat¬ 
ing  in  its  intended  environment  met  the  needed  capability  as  described  in  the 
business  case. 
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Documentation  Descriptions 


Table  C-1.  Documentation  Requirements  for  ACAT  III  Programs 


Required  information 

Description 

Problem  statement 

The  foundation  of  the  business  case  that  serves  to  document  that  a  problem 
exists  and  is  worth  solving.  Its  purpose  is  to  ensure  that  an  analysis  has  been 
done  to  consider  whether  the  business  need  can  be  solved  without  a  materiel 
solution  (results  of  the  DOTMLPF  analysis),  that  external  influences  have  been 
identified,  and  that  success  factors  have  been  defined  and  can  be  measured. 

Program  charter 

A  companion  document  to  the  business  case  that  establishes  the  roles  and 
responsibilities  of  those  involved  in  planning  and  executing  the  program  and 
identifies  the  managerial  methods  for  developing  and  delivering  the  materiel 
solution  described  in  the  business  case.  The  charter  articulates  the  roles  and 
responsibilities  of  the  program  office,  functional  community,  and  contractors. 

Programmatic  environment, 
safety,  and  occupational 
health  evaluation  (PESHE) 

A  repository  for  top-level  environment,  safety,  and  occupational  health  (ESOH) 
management  information,  including  the  following: 

♦  Identification,  assessment,  mitigation,  and  acceptance  of  ESOH  risks 

♦  Ongoing  evaluation  of  mitigation  effectiveness 

♦  Compliance  schedule  for  documentation  related  to  the  National  Environmental 
Policy  Act  (NEPA)  and  Executive  Order  12114,  “Environmental  Effects  Abroad 
of  Major  Federal  Actions.” 

The  PESHE  communicates  the  status  of  ESOH  efforts  and  risk  management  for 
the  system. 

Component  risk 
assessment 

An  examination  of  each  identified  risk  to  refine  the  description  of  the  risk,  isolate 
the  cause,  and  determine  the  effects  in  setting  risk  mitigation  priorities.  The  as¬ 
sessment  considers  the  likelihood  of  root  cause  occurrence;  identifies  possible 
consequences  in  terms  of  performance,  schedule,  and  cost;  and  identifies  the 
risk  level  in  terms  of  risk  rating. 

Test  plan 

Documentation  of  the  strategy  that  will  be  used  to  verify  and  ensure  that  a  prod¬ 
uct  or  system  meets  its  design  specifications  and  other  requirements  and  that 
the  system  can  be  operated,  maintained,  supported,  and  controlled  by  user 
personnel  in  its  intended  operational  environment  with  the  intended  training. 
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Appendix  D 

BCL  Business  Case 


The  business  case  is  the  single  document  used  to  justify  a  DBS  investment  and 
acquisition  decision  in  BCL.  All  DBSs  that  exceed  $  1  million  must  have  a  busi¬ 
ness  case.  The  business  case  ensures  progress  and  outcomes  remain  in  alignment 
and  further  justify  continued  funding  throughout  the  life  cycle  of  the  materiel  so¬ 
lution.  It  must  be  revalidated  upon  any  major  changes  to  scope,  outcomes,  cost, 
schedule,  assumptions,  risks,  constraints,  and  success  factors.  Such  updates  allow 
DoD  to  ensure  that  the  problem  to  be  solved,  the  approach  to  solving  it,  and  the 
benefits  to  be  derived  remain  valid. 

The  business  case  ensures  that  a  problem,  its  root  cause,  and  DOTMLPF-P  issues 
are  thoroughly  analyzed,  that  all  options  are  considered,  that  risks  are  identified, 
and  that  the  expenditure  of  resources  and  funds  can  be  justified  with  a  high  degree 
of  confidence.  The  business  case  provides  leadership  with  sufficient  information 
to  make  informed  investment  decisions  within  the  context  of  enterprise  priorities 
and  available  resources.  The  owning  component  is  responsible  for  the  develop¬ 
ment  and  maintenance  of  the  business  case. 

The  purpose  of  the  business  case  is  to  do  the  following: 

♦  Facilitate  a  way  of  thinking  that  causes  components  to  consider  a  business 
capability’s  value,  risk,  and  relative  priority  as  fundamental  elements  of 
submission. 

♦  Require  those  proposing  a  solution  to  justify  its  value  and  to  self-eliminate 
any  proposals  that  are  not  of  demonstrable  value. 

♦  Enable  DoD  leadership  to  detennine  whether  a  concept  or  proposed  solu¬ 
tion  is  of  value  to  the  enterprise  and  is  achievable  compared  to  the  relative 
merits  of  alternative  proposals. 

♦  Enable  DoD  leadership  to  objectively  measure  the  delivered  benefits. 

The  business  case  provides  a  compelling,  defendable,  and  credible  justification 
for  the  recommended  approach  to  solving  a  defined  problem.  The  problem  is  con¬ 
sidered  solved  upon  reaching  the  stated  objectives,  which  have  financial  and  other 
business  values  made  tangible  through  the  business  case  analysis.  The  business 
case  describes  the  full  range  of  resources  and  actions  required  to  reach  these  ob¬ 
jectives. 

The  business  case  develops  in  stages  based  on  information  known  at  the  time  of 
its  creation.  Business  case  revalidation  and  updates  are  done  throughout  the 
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proposed  solution  and  program’s  life  cycle  as  more  information  becomes  availa¬ 
ble,  technology  changes,  statutes  and  regulations  dictate,  requirements  and  out¬ 
comes  change,  or  other  significant  events  occur. 

The  business  case  development  process  ensures  the  following: 

♦  Thorough  consideration  and  documentation  of  the  required  issues 

♦  Availability  of  sufficient  information  to  facilitate  fair  evaluations  of  dif¬ 
ferent  proposals 

♦  Clarity  of  both  the  value  and  risks  inherent  in  the  proposed  solution 

♦  Commitment  and  sponsorship  of  an  executive  with  the  capability  and  au¬ 
thority  to  deliver  the  benefits 

♦  Ability  to  quantify  all  key  aspects  so  their  achievement  can  be  tracked  and 
measured 

♦  Delivery  of  the  outcomes  and  benefits  that  can  be  tracked  and  measured 

♦  Tailoring  of  the  business  case  to  the  size  and  risk  of  the  proposed  solution 
or  initiative 

♦  Focus  on  the  business  capabilities  and  impact,  rather  than  on  technical 
aspects 

♦  Inclusion  of  all  factors  relevant  to  a  complete  evaluation 

♦  Clearly  relevant  and  logical  contents  that  are  simple  to  evaluate 

♦  Direct  justification  of  key  elements  in  a  transparent  manner 

♦  Clear  accountability  and  commitment  for  the  delivery  of  benefits  and 
management  of  costs. 

The  business  case  will  be  evaluated  by  the  IRB,  DBSMC,  and  MDA  to  ensure  the 
following: 

♦  The  investment  has  value  to  the  enterprise  and  aligns  with  enterprise 
priorities. 

♦  The  proposed  solution  is  properly  managed  and  supported  by  senior 
officials. 

♦  The  scope  for  the  proposed  solution  is  defined  and  desired  outcomes  are 
measurable. 

♦  BPR  has  been  completed  or  is  being  completed. 
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BCL  Business  Case 


♦  The  component  will  be  able  to  deliver  the  benefits. 

♦  Dedicated  resources  are  working  on  the  highest  value  opportunities. 

The  estimated  cost  of  a  proposed  solution  generally  dictates  the  degree  of  scrutiny 
and  the  level  of  detail  in  the  business  case.  The  business  case  will  always  be 
judged  on  the  quality  of  information  it  contains,  not  on  the  length  of  the  content. 

The  primary  sections  of  a  business  case  are  described  below. 

Executive  Summary 


The  executive  summary  illustrates  the  essence  of  the  entire  business  case  by 
providing  a  cogent  summary  of  the  subject,  scope,  methods  of  analysis,  and  major 
results.  This  section  may  provide  historical  information,  but  it  should  be  succinct 
and  include  only  what  is  deemed  directly  relevant  for  providing  context  in  addi¬ 
tion  to  being  understandable  to  the  business  case’s  audience. 

Problem  Statement 


The  problem  statement  clearly  defines  and  articulates  the  business  need  to  be 
solved,  the  value  of  solving  it,  and  the  approach  to  solving  it.  It  presents  infor¬ 
mation  in  such  a  way  that  it  enables  the  decision  makers  to  quickly  make  deci¬ 
sions  and  to  provide  the  context  for  subsequent  analysis  and  execution. 

The  problem  statement  results  from  a  structured  analysis  of  an  aspect  of  the  busi¬ 
ness  where  a  perceived  business  need  exists.  This  stems  from  either  anecdotal 
evidence  or  from  indications  that  the  value  of  an  operational  business  metric  ex¬ 
ceeds  boundaries.  Developing  a  problem  statement  ensures  that  a  problem  actual¬ 
ly  exists,  that  the  root  cause  of  the  symptoms  is  identified,  and  that  the  problem  is 
bounded  and  understood  to  a  level  where  it  can  be  solved  and  desired  outcomes 
can  be  measured.  The  problem  statement  provides  the  foundation  for  the  overall 
business  case  and  requires  IRB  review  and  approval  before  progressing  beyond 
the  BCD  phase. 

The  problem  statement  may  contain  multiple  subsections  that  serve  to  character¬ 
ize  the  business  need.  The  PM  describes  the  need  in  terms  of  the  following 
considerations: 

♦  Defining  the  broader  operational  environment 

♦  Summarizing  the  business  problem  within  the  proper  context 

♦  Describing  how  the  problem  affects  the  current  operating  environment 
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♦  Describing  the  business  need  in  terms  of  underlying  root  cause  and  in  a 
specific,  quantifiable  manner  that  provides  a  clear  description  of  the  cur¬ 
rent  strategic  and  tactical  environment 

♦  Identifying  internal  and  external  boundaries  and  constraints 

♦  Scoping  the  business  need  in  a  way  that  considers  the  boundaries  and  con¬ 
straints  and  that  will  enable  an  incremental  approach  within  BCL  time 
frames 

♦  Describing  potential  DOTMLPF-P  drivers  of  or  contributors  to  the  busi¬ 
ness  need,  and  describing  how  each  driver  contributes  and  how  the  busi¬ 
ness  need  can  be  changed  or  eliminated  if  the  contributor  is  removed 

♦  Identifying  the  expected  benefits  and  improvements,  including  a  descrip¬ 
tion  of  the  desired  end  state  and  identifying  the  metrics  by  which  the  im¬ 
provements  will  be  tracked  and  measured 

♦  Summarizing  the  recommended  course  of  action  upon  which  further 
analysis  and  execution  will  be  based. 

Business  Case  Analysis 


The  business  case  analysis  provides  a  convincing,  defensible,  and  reliable  justifi¬ 
cation  for  the  recommended  approach  to  solving  a  defined  problem.  The  problem 
will  be  considered  solved  upon  reaching  the  stated  objectives,  which  have  finan¬ 
cial  and  other  business  values  that  are  made  tangible  through  the  business  case 
analysis.  This  section  examines  the  full  DOTMLPF-P  range  of  resources  and  ac¬ 
tions  required  to  reach  stated  objectives  and  should  be  clear  in  the  component’s 
effort  to  achieve  a  solution  through  DOTmLPF-P  (nonmateriel)  efforts  before  de¬ 
ciding  on  a  materiel  solution. 

Changes  in  the  problem  scope  must  be  validated  against  the  business  case.  The 
full  range  of  potential  impacts  must  be  understood  before  making  decisions  that 
affect  project  boundaries.  Updating  the  business  case  to  reflect  such  changes  re¬ 
quires  IRB  approval. 

Solution  Scope 


Solution  scope  describes  the  materiel  capabilities  needed  to  solve  the  problem 
identified  in  the  DOTMLPF-P  analysis.  The  solution  scope  section  further  de¬ 
scribes  constraints,  dependencies,  and  business  outcomes.  The  solution  set  is  typi¬ 
cally  defined  with  increasing  detail  over  time. 
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BCL  Business  Case 


Analysis  of  Alternatives 


The  AoA  is  based  on  guidance  provided  by  the  CADA  during  the  BCD  phase  and 
is  summarized  in  the  business  case.  The  AoA  focuses  on  the  alternatives  for  meet¬ 
ing  defined  objectives  and  the  basis  for  deciding  which  alternative  best  meets 
those  objectives  based  on  the  recommended  course  of  action  presented  in  the 
problem  statement. 

Each  alternative  is  evaluated  against  a  set  of  criteria  defined  by  the  program.  At 
minimum,  for  each  viable  alternative,  the  following  should  be  documented: 

♦  Summary  of  the  alternative 

♦  Assessment  of  its  viability 

♦  Estimated  life-cycle  cost  and  benefits  (in  comparison  to  the  status  quo) 

♦  Estimated  risks  and  impact 

♦  Detailed  system  and  business  process  alternatives 

♦  Detailed  cost,  benefit,  and  sensitivity  analyses 

♦  Recommended  course  of  action. 

Program  Justification 


The  program  justification  provides  a  logical  and  defendable  argument  for  why  the 
recommended  material  solution  is  the  preferred  course  of  action.  At  Milestone  A, 
the  program  justification  is  an  estimate;  it  will  mature  as  the  program  develops. 
Subsections  of  the  program  justification  include  summaries  of  the  following: 

♦  Assumptions  underlying  the  solution  analysis 

♦  Business  process  requirements  (relevant  to  BPR  efforts) 

♦  Changes  likely  to  be  required  across  the  DOTMLPF-P  spectrum  to  im¬ 
plement  the  recommended  solution 

♦  Critical  success  factors 

♦  Key  risk  factors 

♦  Financial  analysis 

♦  Sensitivity  analysis 
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♦  Funding  and  resources  required  to  implement  the  solution 

♦  Expected  schedule  for  delivering  the  capability,  including  IOC  and  FDD. 


Acquisition  Plan 


The  acquisition  plan  describes  the  method  for  procuring  the  capability  required  to 
solve  the  business  problem,  if  it  has  been  decided  that  a  nonmaterial  solution 
alone  will  not  solve  it.  It  guides  the  process  of  contracting  for  the  materiel  solu¬ 
tion  and  the  services  required  to  implement  it.  The  acquisition  plan  also  lays  out 
how  the  program  meets  the  statutory  and  regulatory  requirements  for  competition 
and  describes  the  appropriate  types  of  contracts  or  the  contract  vehicles,  if  appro¬ 
priate,  to  implement  the  solution.  Finally,  the  plan  describes  the  process  by  which 
the  government  intends  to  research  the  available  vendors,  small  business  objec¬ 
tives,  incentive  method,  special  contracting  considerations,  evolutionary  acquisi¬ 
tion  approach,  and  approach  to  life-cycle  sustainment.  This  section  of  the  business 
case  includes  summaries  of  the  following: 

♦  Approach  to  the  acquisition  and  the  associated  milestones/decision  points 

♦  Results  of  market  research 

♦  Contracting  approach  to  acquire  the  services  and  goods  required  to  im¬ 
plement  the  recommended  materiel  solution,  including  a  discussion  of 
contract  types,  competition,  sources  identified,  and  consideration  of  small 
businesses 

♦  Process  and  parameters  by  which  the  system  integrator  and  other  vendors 
will  be  selected. 

T est  Plan 


The  test  plan  summarizes  the  planning  for  the  materiel  solution’s  test  strategy  and 
the  technical  approach  to  its  implementation.  Portions  of  this  section  of  the  busi¬ 
ness  case  are  updated  at  specific  milestones  during  the  IM  phase  and  the  Execu¬ 
tion  segment.  The  CADA  approves  the  initial  test  plan  and  updates  submitted  at 
subsequent  decision  points. 
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Appendix  E 

IRB/BPR  Integration 


In  accordance  with  public  law,  an  IRB  must  approve  the  investment  of  funds  (ap¬ 
propriated  and  nonappropriated  sources)  for  new  system  development,  legacy  sys¬ 
tem  modernization  or  enhancement,  or  initiative  or  program  implementation 
greater  than  $1  million  over  the  Future  Years  Defense  Program  (FYDP).  The  Na¬ 
tional  Defense  Authorization  Act  (NDAA)  for  FY2010  added  a  new  requirement: 
system  owners  must  affirm  whether  BPR  was  perfonned  on  such  investments 
from  appropriated  and  nonappropriated  fund  sources.  Public  law  also  requires  pe¬ 
riodic  review,  but  not  less  than  annually,  of  every  DBS  investment,  even  those 
systems  that  are  in  the  O&S  phase.  This  review  examines  the  current  status  of 
DBSs  to  closely  monitor  program  cost,  performance,  and  schedule  risks  and  to 
detennine  whether  adjustments  need  to  be  made  in  those  systems  or  other  systems 
that  are  dependent  on  the  system  under  review. 

The  Office  of  the  Secretary  of  Defense  uses  the  IRB  review  process  to  determine 
whether  an  overlap  or  gap  exists  among  capabilities  for  systems  supporting  DoD 
BEA  operational  activities,  processes,  and  functions.  DoD  components  use  this 
information  to  manage  system  portfolios  to  ensure  optimal  placement  and  use  of 
investment  funds  on  systems  that  support  DoD  business  capabilities.  The  IRB 
process  is  also  used  to  identify  system  interface  infonnation  on  systems  seeking 
certification  that  requires  legacy  system  owners  to  list  a  projected  sunset  date  for 
their  systems.  This  information  is  used  to  facilitate  portfolio  planning  and  to  man¬ 
age  budget  and  investment  fund  allocation  for  systems. 

Section  1072  of  the  FY10  NDAA  integrated  the  requirement  for  BPR  into  the 
DoD’s  IRB  and  the  DBSMC  governance  framework  and  required  that  BPR  de¬ 
terminations  be  made  by  the  DoD  Deputy  Chief  Management  Officer  (DCMO)  or 
one  of  the  military  department  CMOs,  depending  on  which  component’s  business 
processes  the  DBS  modernization  supports. 

Conducting  appropriate  BPR,  starting  up  front  and  continuing  throughout  a 
DBS’s  acquisition  or  modernization  life  cycle,  is  critical  to  improving  DBS  per¬ 
formance.  The  BPR  assessment  is  an  important  step  toward  ensuring  that  pro¬ 
grams  are  given  the  greatest  chance  of  success,  are  fielded  quickly,  and  are 
consistent  with  industry  best  practices.  Conducting  appropriate  BPR  also  helps 
DoD  rationalize  its  DBS  portfolio,  improve  its  use  of  performance  management, 
control  scope  changes,  and  reduce  the  cost  of  fielding  business  capabilities. 
Attachment  E-l  is  a  road  map  for  completing  the  BPR. 
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Though  the  Clinger-Cohen  Act  has  included  a  BPR-like  requirement  for  some 
time,  Section  1072  placed  a  renewed  emphasis  on  BPR  and  integrated  it  into  the 
IRB  and  DBSMC  governance  framework. 

DoD  does  not  mandate  a  specific  BPR  method  within  the  context  of  DBSs. 
However,  it  has  identified  a  number  of  key  BPR  tenets  that  programs  must 
demonstrate: 

♦  Outline  a  clear  and  reasonable  problem  statement. 

♦  Demonstrate  alignment  between  the  investment  and  broader  departmental, 
component,  or  service  goals. 

♦  Complete  analysis  of  the  as-is  environment  in  sufficient  detail  to  illumi¬ 
nate  the  problem  statement  and  root  causes  and  to  justify  the  need  for  a 
particular  materiel  investment. 

♦  Consider  and  implement  changes  across  the  full  spectrum  of  operations  or 
DOTMLPF-P,  in  addition  to  developing  a  materiel  solution. 

♦  Complete  analysis  of  the  to-be  environment  in  sufficient  detail  to  be  trans¬ 
lated  into  clear  requirements  linked  to  the  selected  materiel  solution’s  ca¬ 
pabilities.  This  analysis  must  illustrate  that  the  investment’s  underlying 
business  processes  are  as  streamlined  and  efficient  as  possible. 

♦  Eliminate  or  reduce  unique  requirements  and  associated  reports,  interfa¬ 
ces,  conversions,  extensions  (RICE)  objects  in  commercial  and  govern¬ 
ment  off-the-shelf  implementations  to  the  greatest  extent  possible  through 
appropriate  use  of  AoA  and  fit-gap  analysis. 

♦  Eliminate  or  reduce  unique  interfaces  to  the  greatest  extent  possible  and 
design  information  exchanges  logically  and  efficiently. 

♦  Identify  appropriate  outcome-based  business  perfonnance  measures  that 
are  consistent  and  linked  to  intended  benefits  of  investment. 

♦  Design  a  reasonable  implementation/change  management  approach. 

♦  Detail  actual  results  versus  targets. 

Attachment  E-2  is  an  example  of  a  basic  outline  for  a  BPR  submission. 

To  ensure  a  BPR’s  compliance  with  the  key  tenets,  the  BPR  assessment  process 
uses  both  a  specific  questionnaire  (a  BPR  Assessment  Form)  and  supplemental 
objective  evidence  to  document  a  program’s  BPR.  Attachment  E-3  provides  the 
BPR  Assessment  Fonn. 
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IRB/BPR  integration 


Each  program  should  supplement  its  answers  to  the  BPR  Assessment  Form  with 
program  documentation  to  serve  as  objective  evidence.  Below  are  some  examples 
of  objective  evidence: 

♦  Architectural  diagrams  (OV-5,  OV-6c,  SV-1,  SV-8) 

♦  Other  as-is  and  to-be  process  maps  or  analysis  at  a  level  sufficient  to 
demonstrate  the  business  problem  the  program  addresses 

♦  BCL  problem  statement  or  business  case  documents 

♦  DoD  or  component  strategic  plans 

♦  Baseline  perfonnance  information 

♦  DOTMLPF-P  analysis 

♦  Business  case  analysis 

♦  Requirements  list 

♦  RICE  object  list  and  level-of-effort  analysis 

♦  Governance  or  configuration  control  board  documentation 

♦  Analysis  of  alternatives 

♦  Fit-gap  analysis 

♦  Interface  documentation 

♦  Data  standards  documentation 

♦  Implementation  and  training  plans. 
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BUSINESS  PROCESS  REENGINEERING  ROAD  MAP 
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>  DITPRS 

>  Benchmarking 
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Attachment  E-2 — Example  BPR  Outline 


Shown  below  is  an  example  of  a  basic  outline  for  a  BPR  submission,  with 
standard  deliverables.  The  PM  should  adjust  the  outline  as  needed  to 
accommodate  each  program. 

1 .  Program  name,  DoD  IT  Portfolio  Repository  (DITPR)  number, 
service/agency,  PM  name 

2.  BPR  assessment  team  members 

3.  IRB  infonnation 

a.  System  tier  level 

>  Tier  2 — includes  all  non-Major  Automated  Infonnation  System 
(non-MAIS)  DBS  program  investments  $10  million  or  above 

>  Tier  3 — includes  all  non-MAIS  DBS  program  investments  greater 
than  $1  million  and  less  than  $10  million 

b.  Current  certification  request  ($M) 

4.  Acquisition  type  (When  is  the  development/modernization  approaching  its 
next  milestone?  What  is  it?) 

a.  New  development/modemization,  completed 
development/modemization 

b.  For  AC  AT  acquisition  programs,  indicate  the  next  standard  acquisition 
milestone  or  operational  test  and  evaluation  (OT&E)  event 

c.  Indicate  where  the  acquisition  lifecycle  is  in  the  development/ 
modernization 

d.  Identify  the  legacy  systems  being  eliminated 

5.  Problem  statement  (What  business  problem  are  you  trying  to  solve 
through  this  development/modemization?) 

a.  What’s  wrong? 

b.  How  bad  is  it  (metrics)? 

c.  Where  is  it  occurring? 

d.  When  did  it  start;  how  long  has  it  been  happening? 

e.  What  is  the  impact? 

6.  Strategic  alignment 

a.  Identify  goals  or  objectives  of  the  Department  and  the  Component 
with  which  the  development/modemization  aligns  and  how  it  aligns 

b.  Identify  which  of  the  15  Business  Enterprise  Architecture  (BEA)  end- 
to-end  process  the  system  supports 

>  Acquire-to-Retire  (A2R) 

>  Budget-to-Report  (B2R) 

>  Concept-to-Product  ( C2P) 

>  Cost  Management  (CM) 

>  Deployment-to-Redeployment/Retrograde  (D2RR) 
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>  Environmental  Liabilities  (EL) 

>  Hire-to-Retire  (H2R) 

>  Market-to-Prospect  (M2P) 

>  Order-to-Cash  (02C) 

>  Plan-to-Stock — Inventory  Management  (P2S) 

>  Procure-to-Pay  (P2P) 

>  Proposal-to-Reward  (P2R) 

>  Prospect-to-Order  (P20) 

>  Service  Request-to-Resolution  (SR2R) 

>  Service-to-Satisfaction  (S2S) 

7.  As-is  analysis 

a.  Identify  the  root  causes  of  the  business  problem 

b.  Provide  an  as-is  map,  using  Business  Process  Model  and  Notation 
(BPMN),  of  the  current  process  that  requires  change 

c.  Identify  other  materiel  solutions  (internal  and  external  to  DoD) 
considered  to  meet  the  business  need  and  specify  why  they  were 
eliminated  from  further  consideration 

8.  To-be  analysis 

a.  Provide  a  to-be  map,  in  BPMN,  of  the  target  process  that  illustrates  the 
improvements  to  the  as-is  process  the  effort  will  generate 

b.  Describe  the  business  case/impact,  specifically  how  the  business 
process  to  be  supported  by  the  modernization  is  as  streamlined  and 
efficient  as  possible  through,  for  example,  a  decrease  in  the  number  of 
process  steps  or  the  number  of  people  involved  or  an  increase  in  output 

c.  Identify  the  industry  best  practices/benchmarks  that  were  leveraged  to 
develop  and  evaluate  potential  to-be  processes  and  solution 

d.  Summarize  assessment  of  customer  and  business  requirements 

>  Customer  assessment  (what  the  customer  wants  or  needs,  which 
may  be  strongly  correlated  to  the  “buying  decision”  and  often 
fonns  the  basis  for  comparison) 

>  Business  assessment  (what  the  business  wants  or  needs, 
summarized  as  key  issues  and  translated  into  specific  and 
measurable  requirements) 

e.  Constraining  factors  (What  laws,  regulations,  or  policies  constrain  the 
to-be  process  design  and  prevent  it  from  being  as  streamlined  and 
efficient  as  possible?) 

f.  Unique  requirements  (Were  unique  requirements  and  unique  interfaces 
eliminated  or  reduced?)  How  many  Reports,  Interfaces,  Conversions, 
Enhancements  (RICE)  components  are  planned  as  part  of  the 
development/modemization?  What  is  the  justification  for  each? 

9.  Change  management  plan  that  includes  operating  procedures, 
organization,  training,  interoperability,  personnel,  governance, 
infrastructure,  etc.,  and  that  explains  how  stakeholders  and  solution 
providers  have  been  involved  in  the  creation  of  the  plan 
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IRB/BPR  integration 


10.  Indicate  whether  the  users/customers  have  provided  confirmation  that  they 
are  prepared  for  system  tum-on  and,  if  yes,  in  what  form 

11.  Perfonnance  measures  and,  for  each,  the  baseline/current  perfonnance, 
target  performance,  and  data  source  (What  are  the  operational/business 
measures — such  as  cost  savings  or  cycle  time — that  will  be  used  to  gauge 
the  business  success  of  the  development/modemization?) 

12.  ROI/benefit  estimate  that  delineates  the  metric;  for  example,  if  the  cycle 
time  is  now  30  days  but  will  be  reduced  to  23  days,  the  program  will  save 
7  days,  which  translates  into  a  dollar  savings  of  $1.3  million  over  5  years. 
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Business  Process  Reengineering  Assessment  Form 


Version  30Apr2011 


Please  fully  answer  all  questions,  providing  appropriate  context  and  spelling  out  acronyms  where  appropriate.  When  providing 
reference  material  or  objective  evidence  to  answer  a  question,  please  ensure  that  the  materials  are  submitted  with  this  form  and  that 
it  is  readily  apparent  which  parts  of  the  materials  are  relevant  to  which  questions  on  this  form. 

Program  Information 


Program  Name: 

DITPR  Number: 

Click  here  to  enter  text. 

Click  here  to  enter  text. 

Acronym: 

Component: 

Click  here  to  enter  text. 

Click  here  to  enter  text. 

Program  Manager: 
Organization: 

Click  here  to  enter  text. 

Click  here  to  enter  text. 

Phone  Number: 

Email: 

Click  here  to  enter  text. 

Click  here  to  enter  text. 

Functional  Sponsor: 
Organization: 

Click  here  to  enter  text. 

Click  here  to  enter  text. 

Phone  Number: 

Email: 

Click  here  to  enter  text. 

Click  here  to  enter  text. 

CMO/PCA  Name: 
Organization: 

Click  here  to  enter  text. 

Click  here  to  enter  text. 

Phone  Number: 

Email: 

Click  here  to  enter  text. 

Click  here  to  enter  text. 

BPR  POC: 

Organization: 

Click  here  to  enter  text. 

Click  here  to  enter  text. 

Phone  Number: 

Email: 

Click  here  to  enter  text. 

Click  here  to  enter  text. 

IRB  Information 

Primary  IRB:  Select- 

d 

IRB  Meeting  Date:  Click  here  to  enter  a  date.  System  Tier  Level: 
Current  Certification  Request  ($M):  Click  here  to  enter  text. 


Select.. 


i 


Acquisition  Information 

1.  Is  this  a  (check  one): 

0New  development  effort  Q  Modernization  Q Completed  development/modernization 

a.  Where  in  the  acquisition  lifecycle  is  this  development/modernization? 


Select... 


* 


b.  When  is  the  development/modernization  approaching  its  next  milestone?  What  is  it?  For 
ACAT  acquisition  programs,  if  you  are  pre-delivery,  please  indicate  the  next  standard 
acquisition  milestone  or  Operational  Test  &  Evaluation  event.  If  you  are  already  delivering 
capability,  please  indicate  when  the  next  increment  of  capability  will  be  delivered.  For 
non-ACAT  acquisition  programs,  please  indicate  the  next  major  program  event 

or  acquisition  decision.  For  modernizations,  please  indicate  when  the  modernization  is 
scheduled  to  be  complete  or  if  capability  will  be  delivered  in  increments,  when  the  next 
increment  of  capability  will  be  delivered. 

Click  here  to  enter  text. 

c.  If  applicable,  which  legacy  systems  are  being  sunset  because  of  this 
development/modernization  (Include  DITPR  #s)?  When  are  they  being  sunset?  Is  it  full  or 
partial  sunsetting? 

Click  here  to  enter  text. 
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d.  If  applicable,  when  is  this  program  going  to  be  sunset?  Is  it  full  or  partial  sunsetting? 
(If  you  are  listed  as  a  legacy  system,  you  must  answer  this  question.  If  you  don't  know, 
indicate  as  such.) 

Click  here  to  enter  text. 

Problem  Statement 

2.  What  business  problem  are  you  trying  to  solve  through  this  development/modernization? 

Click  here  to  enter  text. 

Strategic  Alignment 

3.  Which  goals  or  objectives  of  the  QDR,  SMP,  Performance  Budget,  HPPGs,  and/or 
Component  Strategic  Plan  does  this  development/modernization  align  with?  How  does  it 
align? 

Click  here  to  enter  text. 

4.  Which  of  the  15  BEA  End-to-End  Processes  does  this  system  support?  Additional 
information  is  at:  http://www.bta.mil/products/bea  7  O/BEA/html  files/end2end.html. 

( Check  all  that  apply) 

None 

Acquire -to -Ret  ire 
Budget-to-Report 
Concept-to-Product 
Cost  Managment 

Deployment-to-Redeployment/Retrograde 

Environmental  Liabilities 

Hire-to-Retire 

Market-to-Prospect 

Order-to-Cash 

PI  a  n-to-Stock...  Inventory  Management 

Procure-to-Pay 

Proposal-to-Reward 

Prospect-to-Order 

Service  Request-to-Resolution 

Service-to-Satisfaction 

As-Is  Analysis 

5.  What  are  the  root  causes  of  the  business  problem  identified  above? 

Click  here  to  enter  text. 
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6.  Have  you  completed  an  As-Is  map  of  the  current  process  that  illustrates  the  specific 
problem  that  requires  change?  If  yes,  include  objective  evidence. 

HYes  QNo 

7.  What  non-materiel  solutions  are  you  implementing  across  the  full  spectrum  of  operations 
to  address  the  business  problem?  For  example,  process,  organizational,  or  training  changes. 
Why  are  non-materiel  solutions  alone  insufficient  to  solve  the  business  problem? 

Click  here  to  enter  text. 

8.  What  other  existing  materiel  solutions  (internal  and  external  to  DoD)  did  you  consider  to 
meet  your  business  need?  Why  were  these  other  solutions  unable  to  meet  the  business  need? 

Click  here  to  enter  text. 

To-Be  Analysis 

9.  Have  you  completed  a  To-Be  map  of  the  target  process  that  illustrates  the  improvements 
to  the  As-Is  process  that  this  effort  will  generate?  If  yes,  include  objective  evidence. 

QYes  HNo 

10.  Explain  how  the  business  process  to  be  supported  by  the  development/modernization  is 
as  streamlined  and  efficient  as  possible?  For  example,  have  you  reduced  the  number  of 
process  steps  or  the  number  of  people  involved  in  the  process  or  have  you  increased 
throughput,  etc? 

Click  here  to  enter  text. 

11.  Which  industry  best  practices/benchmarks  were  leveraged  to  develop  and  evaluate 
potential  to-be  processes  and  solutions?  For  example,  did  you  consult  with  industry  leaders, 
use  the  SCOR  model  or  an  equivalent,  incorporate  written  government  best  practices, 
incorporate  industry  leading  performance  measures,  etc? 

Click  here  to  enter  text. 

12.  How  have  you  engaged  key  stakeholders  in  your  BPR  process  to  ensure  that  they  are 
willing  to  change  their  processes/operations  as  needed? 

Click  here  to  enter  text. 

13.  What  are  the  laws,  regulations,  and/or  policies  that  constrain  your  To-Be  process  design 
and  prevent  it  from  being  as  streamlined  and  efficient  as  possible?  How  do  they  constrain 
you? 

Click  here  to  enter  text. 

14.  How  have  you  eliminated  or  reduced  the  need  for  unique  requirements  and  unique 
interfaces?  How  many  RICE  objects  are  planned  as  part  of  this  development/modernization? 
Break  them  down  by  Reports,  Interfaces,  etc.  What  is  the  justification  for  the  key  RICE 
objects? 

Click  here  to  enter  text. 

Business  Performance  Measures 

15.  What  are  your  operational/business  measures,  linked  to  your  problem  statement,  that 
you  will  use  to  gauge  the  business  success  of  the  development/modernization?  For  example, 
cost  savings  measures,  cycle  time  measures,  etc.  For  each  measure,  identify  the 
baseline/current  performance,  target  performance,  and  data  source. 

Click  here  to  enter  text. 
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Implementation/Chanqe  Management 

16.  Have  you  developed  an  implementation/change  management  plan  that  includes: 
operating  procedures,  organization,  training,  interoperability,  personnel,  governance, 
infrastructure,  etc?  How  have  your  stakeholders  and  solution  providers  been  involved  in  the 
creation  of  this  plan? 

Click  here  to  enter  text. 

17.  Have  the  users/customers  provided  confirmation  that  they  are  prepared  for  system  turn¬ 
on?  If  yes,  in  what  form? 

Click  here  to  enter  text. 

Results 

18.  Briefly  describe  the  results  you  have  obtained  using  BPR. 

Click  here  to  enter  text. 

Business  Process  Reengineering 

19.  Briefly  include  any  additional  comments  on  your  BPR  process?  If  you  have  not  conducted 
BPR  or  do  not  believe  you  need  to  conduct  BPR,  explain  why?  If  you  have  a  plan  to  conduct 
BPR,  explain  what  that  plan  consists  of? 

Click  here  to  enter  text. 
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Appendix  F 

Program  Charter 


The  program  charter  articulates  how  the  program  will  be  managed.  It  does  not 
represent  a  contract. 

The  program  charter  is  an  evolving  document  to  which  the  program  manager  adds 
detail  as  the  program  matures.  Scope  and  requirement  clarifications,  input  based 
on  the  selected  vendor’s  method,  changes  to  roles  and  resources,  and  changes  in 
executive  direction  continually  feed  the  program  charter,  ensuring  that  the  pro¬ 
gram’s  guiding  document  always  reflects  executive  leadership’s  and  program 
management’s  current  approach  and  expectations  regarding  the  program. 

The  key  sections  of  the  program  charter  are  described  below. 

Mission  Statement 


This  section  describes,  at  a  high  level,  how  the  program  intends  to  execute  the 
solution  defined  in  the  business  case. 

Program  Organization 


This  section  describes  the  program’s  organizational  structure  and  identifies  its  key 
stakeholders.  Critical  pieces  of  infonnation  within  the  program  organization  sec¬ 
tion  are  as  follows: 


♦  Identification  of  the  Component  Functional  Sponsor  and  a  succession  plan 

♦  Graphic  of  the  program/organizational  structure  and  identification  of  the 
roles  and  responsibilities  of  the  organization’s  members 

♦  Description  of  all  key  functional  roles  (customer  definition) 

♦  Documentation  of  the  roles  of  stakeholders  with  a  vested  interest  in 
program  outcomes. 

Resource  Management  Plan 


This  section  describes  how  the  program  management  team  plans  to  ensure  the 
availability  to  the  program  of  the  right  skill  sets  when  they  are  needed  and  at  the 
level  at  which  they  must  be  committed  to  the  program.  This  section  also  shows 
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the  processes  by  which  team  members  join  or  exit  the  program;  these  processes 
ensure  minimal  downtime  and  maximum  knowledge  transfer. 


Governance  Framework 


This  section  introduces  the  processes  that  manage  the  solution  implementation.  It 
describes  how  leadership  ensures  that  the  proper  standards  and  processes  are  fol¬ 
lowed  and  that  they  achieve  their  intended  result.  This  section  may  require  revi¬ 
sion  after  contract  award  to  align  the  system  integrator’s  implementation  approach 
with  the  program.  Key  pieces  of  information  captured  within  the  governance 
framework  section  include  the  following: 

♦  Discussion  of  the  implementation  management  processes 

♦  Processes  by  which  external  parties  engage  with  the  program 

♦  Issue  resolution  process 

♦  Status  reporting,  including  program  metrics 

♦  Risk  management  approach 

♦  Contract  management  system,  including  change  process  and  description  of 
contractor  deliverables 

♦  Scope  management  process 

♦  Engagement  of  the  testing  and  systems  engineering  communities. 

Implementation  Method 


This  section  describes  the  approach  to  be  used  to  implement  the  solution,  includ¬ 
ing  any  phases  or  key  events.  The  vendor’s  method  should  be  used  as  the  basis  of 
this  section  of  the  program  charter.  This  section  remains  blank  until  a  system  in¬ 
tegrator  is  selected  and  engaged. 

Program  Standards 


This  section  discusses  operational  aspects  of  program  management  that  benefit 
from  fonnal  standards  (e.g.,  organizational  change  management,  communication 
planning,  training,  testing,  document  management/version  control,  software  con¬ 
figuration  management,  control  plan,  and  coding).  It  focuses  on  what  standards 
will  be  created,  not  the  documentation  of  the  standards  themselves.  This  section 
requires  revision  after  the  system  integrator  is  engaged,  to  be  consistent  with  the 
contractor’s  implementation  approach  or  method. 
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Appendix  G 

IT  Considerations  for  DBS  Acquisitions 


The  Clinger-Cohen  Act  of  1996  (40  U.S.C.  §  1 1 103,  1 1313,  and  1 1317  and  Subti¬ 
tle  III)  applies  to  all  IT  investments: 

♦  For  all  programs  that  acquire  IT,  at  any  ACAT  level,  the  MDA  must  not 
initiate  a  program  or  an  increment  of  a  program  or  approve  entry  into  any 
phase  of  the  acquisition  process,  and  the  DoD  component  must  not  award 
a  contract,  until  these  conditions  have  been  met  in  accordance  with  CCA: 

>  The  PM  has  satisfied  the  requirements  of  the  CCA. 

>  The  component  CIO  has  confirmed  CCA  compliance. 

♦  The  CCA  requirements  must  be  satisfied  to  the  maximum  extent  practica¬ 
ble  through  documentation  developed  under  the  BCL.  Table  G-l  details 
the  actions  required  to  comply  with  Subtitle  III  of  the  CCA.  The  Compo¬ 
nent  Functional  Sponsor,  in  conjunction  with  the  acquisition  community, 
is  accountable  for  actions  1-5,  and  the  PM  is  accountable  for  actions  6-11. 
The  PM  prepares  a  table  similar  to  Table  G-l  to  indicate  which  documents 
(including  page  and  paragraph)  correspond  to  CCA  requirements.  The 
component  CIO  uses  the  documents  cited  in  the  table  prepared  by  the  PM 
to  assess  and  confirm  CCA  compliance. 

Table  G-1.  Actions  Required  to  Comply  with  Subtitle  III  of  the  Clinger-Cohen  Act 


Action 

Applicable  program  documentation  a 

1.  Determine  that  the  acquisition  supports  core  priority  DoD  functions  b 

Business  case,  program  charter 

2.  Establish  outcome-based  performance  measures  linked  to  strategic 
goals  b 

Business  case,  APB  approval 

3.  Redesign  the  processes  that  the  system  supports  to  reduce  costs, 
improve  effectiveness,  and  maximize  the  use  of  COTS  technology  b 

Business  case,  program  charter 

4.  Determine  that  no  private-sector  or  government  source  can  better 
support  the  function 

Business  case,  program  charter 

5.  Conduct  an  AoA 

Business  case  (AoA) 

6.  Conduct  a  DoD  component  cost  analysis  that  includes  a  calculation 
of  the  return  on  investment 

Business  case  (cost  analysis) 

7.  Develop  clearly  established  measures  and  accountability  for  program 
progress 

Business  case  (APB) 

8.  Ensure  that  the  acquisition  is  consistent  with  global  information  grid 
policies  and  architecture,  including  relevant  standards  c 

APB  (net-ready  KPP,  business  case 
information  exchange  requirements) 
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Table  G-1.  Actions  Required  to  Comply  with  Subtitle  III  of  the  Clinger-Cohen  Act 


Action 

Applicable  program  documentation  a 

9.  Ensure  that  the  program  has  an  information  assurance  strategy  that 
is  consistent  with  DoD  policies,  standards,  and  architectures  b 

AIAS 

10.  Ensure,  to  the  maximum  extent  practicable,  that  modular  contracting 
has  been  used  and  that  the  program  is  being  implemented  in  phased, 
successive  increments,  each  of  which  meets  part  of  the  mission  need 
and  delivers  measurable  benefit,  independent  of  future  increments 

Business  case 

1 1 .  Register  mission-critical  and  mission-essential  systems  with  the 

DoD  CIO  b 

DITPR 

a  The  documents  cited  are  examples  of  the  most  likely  (but  not  the  only)  references  for  the  required  information.  If 
other  references  are  more  appropriate,  they  may  be  used  in  addition  to  or  instead  of  those  cited.  References  should 
include  page  and  paragraph  numbers,  where  appropriate. 

b  These  actions  are  also  required  to  comply  with  Section  81 1  of  Public  Law  1 06-398,  Floyd  D.  Spence  National 
Defense  Authorization  Act  for  Fiscal  Year  2001 ,  October  30,  2000. 
c  DoDI  8410.02,  ANSI  EIA  748-A-1998  (R2002). 

Before  providing  Milestone  A  approval  for  an  IT  business  system,  the  MDA 
makes  a  detennination  that  the  system  will  achieve  IOC  within  5  years,  as  estab¬ 
lished  in  Section  811  of  Public  Law  109-364,  John  Warner  National  Defense  Au¬ 
thorization  Act  for  Fiscal  Year  2007,  October  17,  2006. 

For  DBS  acquisition  programs  that  have  modernization  funding  exceeding  $1  mil¬ 
lion,  the  MDA  must  not  grant  any  milestone,  FDD,  or  their  equivalent,  and  the 
authority  to  obligate  funding  must  not  be  granted  until  the  certification  in  para¬ 
graph  (a)  of  10  U.S.C.  §  2222  has  been  approved  by  the  DBSMC. 

When  the  use  of  commercial  IT  is  considered  viable,  the  PM  must  ensure  maxi¬ 
mum  use  of  and  coordination  with  the  DoD  enterprise  software  initiative. 
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Appendix  H 

Abbreviations 


ACAT 

Acquisition  Category 

ADM 

Acquisition  Decision  Memorandum 

AIAS 

Acquisition  Information  Assurance  Strategy 

ANSI 

American  National  Standards  Institute 

AoA 

Analysis  of  Alternatives 

APB 

Acquisition  Program  Baseline 

BCD 

Business  Capability  Definition 

BCL 

Business  Capability  Lifecycle 

BEA 

Business  Enterprise  Architecture 

BPM 

Business  Process  Management 

BPMN 

Business  Process  Model  and  Notation 

BPR 

Business  Process  Reengineering 

CADA 

Component  Acquisition  Decision  Authority 

CAE 

Component  Acquisition  Executive 

CCA 

Clinger-Cohen  Act 

CIO 

Chief  Infonnation  Officer 

CMO 

Chief  Management  Officer 

COTS 

Commercial  off-the-Shelf 

DAG 

Defense  Acquisition  Guidebook 

DAU 

Defense  Acquisition  University 

DAW  I A 

Defense  Acquisition  Workforce  Improvement  Act 

DBS 

Defense  Business  System 

DBSMC 

Defense  Business  Systems  Management  Committee 

DCMO 

Deputy  Chief  Management  Officer 

DITPR 

DoD  Information  Technology  Portfolio  Repository 

DMS 

Data  Management  Strategy 

DoD 

Department  of  Defense 

DoDI 

DoD  Instruction 
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DOTmLPF-P 

DOTMLPF-P 

DTM 

EA 

EIA 

E.O. 

ESHO 

EV 

FD 

FDD 

FOC 

FYDP 

GIG 

IM 

IOC 

IOT&E 

IRB 

ISP 

IT 

KPP 

LCSP 

MAIS 

MDA 

MDD 

MS 

NDAA 

NEPA 

O&S 

OSD 

OT&E 

PCA 


Doctrine,  Organization,  Training,  Materiel,  Leadership  and  Education, 
Personnel,  Facility,  and  Policy  (nonmateriel) 

Doctrine,  Organization,  Training,  Materiel,  Leadership  and  Education, 
Personnel,  Facility,  and  Policy 

Directive-Type  Memorandum 

Economic  Analysis 

Electronic  Industries  Alliance 

Executive  Order 

Environment,  Safety,  and  Occupational  Health 

Earned  Value 

Full  Deployment 

Full  Deployment  Decision 

Full  Operational  Capability 

Future  Years  Defense  Program 

Global  Infonnation  Grid 

Investment  Management 

Initial  Operational  Capability 

Initial  Operational  Test  and  Evaluation 

Investment  Review  Board 

Information  Support  Plan 

Information  Technology 

Key  Performance  Parameter 

Lifecycle  Sustainment  Plan 

Major  Automated  Information  System 

Milestone  Decision  Authority 

Materiel  Development  Decision 

Milestone 

National  Defense  Authorization  Act 
National  Environmental  Policy  Act 
Operations  and  Support 
Office  of  the  Secretary  of  Defense 
Operational  Test  and  Evaluation 
Pre-Certification  Authority 
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Abbreviations 


PDR 

Preliminary  Design  Review 

PESHE 

Programmatic  Environment,  Safety,  and  Occupational  Health  Evaluation 

PIR 

Post-Implementation  Review 

PM 

Program  Manager 

RFP 

Request  for  Proposals 

RICE 

Reports,  Interfaces,  Conversions,  Extensions 

T&E 

Test  and  Evaluation 

u.s.c. 

United  States  Code 

USD(AT&L) 

Under  Secretary  of  Defense  (Acquisition,  Technology  and  Logistics) 
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